Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp454643pxu; Tue, 6 Oct 2020 10:16:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw4NpS4dniIHUHuEe5jGqLTNCV21Luva/bks180dwCU22kq2Hs391zKgojoTgRD4mD+XCTI X-Received: by 2002:a17:906:a59:: with SMTP id x25mr517056ejf.489.1602004606120; Tue, 06 Oct 2020 10:16:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602004606; cv=none; d=google.com; s=arc-20160816; b=alNWWvWbXv+8ki3CWK8yd1ir/9vdX8me79uc9n9FAWcSMM7KxWjuNKJpZd3qPeWWGW 9mJFaD7n8a71cGEVA/qvRSGT8OUOE4tC82golodY9C2GJURGgFfptEfw+p0gwhD5tLgW WMWQcuhuikOnnT5wsTs4f6m5H8y4NV8iLWOdFnV28PUG06eubEKS8XWh721+cOeHQWAs mE+9lqXV4FW0HoMB8oLSfgXZxlKcQi0Qs7ibvBkfeQ1MAjzN9/q6dZKvfzLtuwHPlx7w m4a6n/JfYZlHnl9In9iKuGYFvOJGGwN6tTNHstYKtLpvmLS743xKtwZcDKibYaYiJETF vjnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=fus0GuCBy+PUOs13nkiYMRRj5ZLVf0qK2djsulwqdqg=; b=d+Y80BUkcIAk1XODjVHVcqMw6ppaLkDeFm7WIOOyjKU9pexpsGF2BL9M8m6e0PbkEr OhSARXrNPPpBXVavBwjl6N6I3oJQGsxDjv2yqhGDkDiGWirxx1Psmzqtvl8vMQvqNxSe LD09yQdTrCeGOdk13lyToTyT+LEaRPDtmQ9EmCYo9oayQd8EZLnCTlg8dU71SH3JzT5G Qk4lGaAWER2xJA6OZigmlvTJGOxP499kXXIoWG3Q1r9dVoGCXlgaR0P610UM3BGjFRSN g49NnSbYAy101LDWEcIptTSQxmVd5Y4y8Cu3YJvC7sHMgld9hWm99frCULSEDUwUJH73 Whdw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Bk04IsZc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j14si2861289edy.562.2020.10.06.10.16.21; Tue, 06 Oct 2020 10:16:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Bk04IsZc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726128AbgJFROq (ORCPT + 99 others); Tue, 6 Oct 2020 13:14:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32900 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725769AbgJFROp (ORCPT ); Tue, 6 Oct 2020 13:14:45 -0400 Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66022C061755 for ; Tue, 6 Oct 2020 10:14:44 -0700 (PDT) Received: by mail-il1-x143.google.com with SMTP id q7so6330046ile.8 for ; Tue, 06 Oct 2020 10:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fus0GuCBy+PUOs13nkiYMRRj5ZLVf0qK2djsulwqdqg=; b=Bk04IsZcOEuvw2B6hkoY1Bew1ab1UXV3YB29ea+qqrItVOVg72gyzYK5cKWISsZxzD 3my4cqx7aWXt80HytX+4VyQYXjHRvzdHSpvu4t9O0vCzbAg73w2zEFQzIjnBehq5Xach iyJFAFmA0f6apOpCPuaI3tL1K0Z/xT3b19en0gRpDCMMvyARsBezWAOBAVISnvSFOiWH Boxoe3/CNgeMIDuwWYy5IJqIs/17TA1gyjUIr0qYg1t/lfcSZAOqJ4QO3UtLOzBhrrHV Bl7TWiE91cqUIwjsU1EgKtWbbBGYoipkeRWEw9a3diPdPRgV54vsjhW7Q/U4SdH0zv7U dQ7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fus0GuCBy+PUOs13nkiYMRRj5ZLVf0qK2djsulwqdqg=; b=P3yJQE8HgNdKrdSqY2Xdhuo3u/bgxLJgKvCLNDts4jC66SKS+5bsyiWzxa8Rc+eets 0wlYhFyyckbeUslAove1gBrQH7/FfZXty6mBxRK2PaETl+p1WT8/uHh0OHtS7een2lWE EQXDCvrRjtqtKxxQt0ZjkRYxX2gNWjA3onIV+FtGr17Qe1d1bZra9imOyF59P/ARR/Rd TSsakSdrPzNNQ+VWo2vnrlxpRcRjivbaAMPMDQlCsChoWo1kf3rhiD7D4tVnO8v76R3g sRxgvpZ2NkCBSJMH9CbCOuXeQcSlpTjNdwpBXT+aTG5BHDQAyOuvog+psoySde0uqHFV IVCw== X-Gm-Message-State: AOAM533qDxoYXM6gvSCHebq8DB/+KLxdSJuTFgDdc1T1V2R6mxpc/nAR G3a8+R3PjfwvBL8dZ4xp25FaOfM3wh+LV3jIVA== X-Received: by 2002:a92:4188:: with SMTP id o130mr4141165ila.27.1602004483736; Tue, 06 Oct 2020 10:14:43 -0700 (PDT) MIME-Version: 1.0 References: <4b3b4fbf8e9806840135e95cef142a0adefc3455.1601925251.git.luto@kernel.org> In-Reply-To: <4b3b4fbf8e9806840135e95cef142a0adefc3455.1601925251.git.luto@kernel.org> From: Brian Gerst Date: Tue, 6 Oct 2020 13:14:32 -0400 Message-ID: Subject: Re: [PATCH 1/2] x86/stackprotector/32: Make the canary into a regular percpu variable To: Andy Lutomirski Cc: "the arch/x86 maintainers" , LKML , "Christopherson, Sean J" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 5, 2020 at 3:31 PM Andy Lutomirski wrote: > > On 32-bit kernels, the stackprotector canary is quite nasty -- it is > stored at %gs:(20), which is nasty because 32-bit kernels use %fs for > percpu storage. It's even nastier because it means that whether %gs > contains userspace state or kernel state while running kernel code > sepends on whether stackprotector is enabled (this is > CONFIG_X86_32_LAZY_GS), and this setting radically changes the way > that segment selectors work. Supporting both variants is a > maintenance and testing mess. > > Merely rearranging so that percpu and the stack canary > share the same segment would be messy as the 32-bit percpu address > layout isn't currently compatible with putting a variable at a fixed > offset. > > Fortunately, GCC 8.1 added options that allow the stack canary to be > accessed as %fs:stack_canary, effectively turning it into an ordinary > percpu variable. This lets us get rid of all of the code to manage > the stack canary GDT descriptor and the CONFIG_X86_32_LAZY_GS mess. > > This patch forcibly disables stackprotector on older compilers that > don't support the new options and makes the stack canary into a > percpu variable. This doesn't consider !SMP builds, where per-cpu variable are just normal variables, and the FS segment is disabled. Unfortunately, -mstack-protector-guard-reg=ds is not accepted. The simplest fix would be to define __KERNEL_PERCPU when either SMP or STACKPROTECTOR are enabled. -- Brian Gerst