From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 20B99C4363D for ; Wed, 7 Oct 2020 01:16:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A23B8206BE for ; Wed, 7 Oct 2020 01:16:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602033384; bh=larqh/Ss0SS1K6WLUhcJSM7WQfj+/MkCFwSauHcYI30=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=rsL0JJh5bYQ8nsjsCwaEvKxHhPYqY3v9dz6DjAzQslnayDBYNBk/+aJ5vn2bD9hNU HBG7FTLX4P3M5YHXugoFK14Lr+J7WDf8lZZczfUT3i9Kt5aTgMLZrnH2f1NJmgzPDK ZOS2UnDDMvbypUEPk7zBv/55cSPj3ZvpXvKvOW/I= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726980AbgJGBQX (ORCPT ); Tue, 6 Oct 2020 21:16:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:60718 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725996AbgJGBQX (ORCPT ); Tue, 6 Oct 2020 21:16:23 -0400 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 15E7E207EA for ; Wed, 7 Oct 2020 01:16:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602033382; bh=larqh/Ss0SS1K6WLUhcJSM7WQfj+/MkCFwSauHcYI30=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=IPIkDm/YmZl+Zli/+slyQg7Xb0SXOC8Pj+XOdIxNQRxIGPes77SessZzdxSbaa3w5 1GNMaqJZVzQduHpgZuY/2Hm4uincpHlUaaRgC8aPSVtZVOUudp52UYHBv808e5Gyi/ bbQ+TD1MhCttbMRD6aItBbPcvh4EE7qpvUcHpWqU= Received: by mail-wr1-f49.google.com with SMTP id t10so262665wrv.1 for ; Tue, 06 Oct 2020 18:16:22 -0700 (PDT) X-Gm-Message-State: AOAM530Y5q6AEc4u7+FhaXYuIFxrvb7Momw9fTsVtTH6TNal1BQ3yTo4 8Xl0cMK4eKs+QrzKoX+yHQ2/1rwthQCV60i2E7TAOQ== X-Google-Smtp-Source: ABdhPJz8FM/uMEtB1LjafBVpbEgvN8M+AHJZ5Aw7WZ1OMaLTJTfrFm6GbWju6C6yaFjZQtVXqY8kt8pGPOj2H+hwcdQ= X-Received: by 2002:adf:a3c3:: with SMTP id m3mr616084wrb.70.1602033380467; Tue, 06 Oct 2020 18:16:20 -0700 (PDT) MIME-Version: 1.0 References: <4b3b4fbf8e9806840135e95cef142a0adefc3455.1601925251.git.luto@kernel.org> In-Reply-To: From: Andy Lutomirski Date: Tue, 6 Oct 2020 18:16:07 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] x86/stackprotector/32: Make the canary into a regular percpu variable To: Brian Gerst Cc: Andy Lutomirski , "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 Tue, Oct 6, 2020 at 10:14 AM Brian Gerst wrote: > > 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. I don't love this because it breaks the "stack canary is just a regular PERCPU variable" idea. GCC accepts -mstack-protector-guard=global to get rid of the segment override, but then it ignores -mstack-protector-guard-offset=stack_canary. So I could do this: #ifdef CONFIG_SMP EXPORT_PER_CPU_SYMBOL(stack_canary); #else /* * GCC can't use a symbol called 'stack_canary' as the stack canary with * an FS or GS segment override, and SMP=n percpu variables are just normal * variables. But GCC can use '__stack_chk_guard'. */ extern unsigned long __attribute__((alias("stack_canary"))) __stack_chk_guard; EXPORT_SYMBOL(__stack_chk_guard); #endif Or I suppose I could just rename the thing __stack_chk_guard. The only downside of the latter seems to be that an accidental mix of SMP and !SMP object files (or modules!) would crash, but I suppose they likely crash anyway.