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=-10.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 08B8CC433DF for ; Fri, 9 Oct 2020 17:42:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 715CF207CD for ; Fri, 9 Oct 2020 17:42:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="vUhERsT7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 715CF207CD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B7EB26B005D; Fri, 9 Oct 2020 13:42:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B07796B0068; Fri, 9 Oct 2020 13:42:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1D736B006C; Fri, 9 Oct 2020 13:42:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0044.hostedemail.com [216.40.44.44]) by kanga.kvack.org (Postfix) with ESMTP id 71C536B005D for ; Fri, 9 Oct 2020 13:42:46 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id EE4E4181AE868 for ; Fri, 9 Oct 2020 17:42:45 +0000 (UTC) X-FDA: 77353107090.21.tin06_6213d4f271e2 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id CA7DB180442C2 for ; Fri, 9 Oct 2020 17:42:45 +0000 (UTC) X-HE-Tag: tin06_6213d4f271e2 X-Filterd-Recvd-Size: 12000 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Fri, 9 Oct 2020 17:42:45 +0000 (UTC) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (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 CAAAE2226B for ; Fri, 9 Oct 2020 17:42:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602265364; bh=gUOFuwn0cjC/he11EKalMfxi4MeQUBOwGoQDNcWNbT8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=vUhERsT7oViNCbN1yktcMSLrq2UoiL+noUEm/Nye3+FW9gP3EmlaS86YkwsSmaEix VKEv0b99m6WYBTuDlZn2jRkrcKSPZWQCkuG0rlY9WIYSzqWA12nvkNsx/DBwy+Z+Qu 294/O/M6pWO1Cn6Y2Yz1mQFSimhCMSQLopcfyo3Q= Received: by mail-wr1-f43.google.com with SMTP id n18so11151405wrs.5 for ; Fri, 09 Oct 2020 10:42:43 -0700 (PDT) X-Gm-Message-State: AOAM531tr+RQcaNdsBGkImIlNJ+/PT5P5OzqbmTwfg3C6EBB+mm2vk8z U7eS2FAs646zdy4z9MrYHlQnCfAZQOM1e5zIJn+VXw== X-Google-Smtp-Source: ABdhPJzf70K4oYcxfMAjLVRVkzKqNGakkCA08giq0JSBoVJW1VDse/vwgNbdxjH+Vx69hTz8VQgAVnajSUf1U4ZTUOo= X-Received: by 2002:a5d:5281:: with SMTP id c1mr16067721wrv.184.1602265362208; Fri, 09 Oct 2020 10:42:42 -0700 (PDT) MIME-Version: 1.0 References: <99B32E59-CFF2-4756-89BD-AEA0021F355F@amacapital.net> <79d1e67d-2394-1ce6-3bad-cce24ba792bd@intel.com> In-Reply-To: From: Andy Lutomirski Date: Fri, 9 Oct 2020 10:42:30 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v13 8/8] x86/vsyscall/64: Fixup Shadow Stack and Indirect Branch Tracking for vsyscall emulation To: "Yu, Yu-cheng" Cc: Andy Lutomirski , "H.J. Lu" , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , LKML , "open list:DOCUMENTATION" , Linux-MM , linux-arch , Linux API , Arnd Bergmann , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , Weijiang Yang , Pengfei Xu Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Oct 6, 2020 at 12:09 PM Yu, Yu-cheng wrote: > > On 10/1/2020 10:26 AM, Andy Lutomirski wrote: > > On Thu, Oct 1, 2020 at 9:51 AM Yu, Yu-cheng wrote: > >> > >> On 9/30/2020 6:10 PM, Andy Lutomirski wrote: > >>> On Wed, Sep 30, 2020 at 6:01 PM H.J. Lu wrote: > >>>> > >>>> On Wed, Sep 30, 2020 at 4:44 PM Andy Lutomirski wrote: > >> > >> [...] > >> > >>>>>>>>> From 09803e66dca38d7784e32687d0693550948199ed Mon Sep 17 00:00:00 2001 > >>>>>>>>> From: Yu-cheng Yu > >>>>>>>>> Date: Thu, 29 Nov 2018 14:15:38 -0800 > >>>>>>>>> Subject: [PATCH v13 8/8] x86/vsyscall/64: Fixup Shadow Stack and > >>>>>>>>> Indirect Branch > >>>>>>>>> Tracking for vsyscall emulation > >>>>>>>>> > >>>>>>>>> Vsyscall entry points are effectively branch targets. Mark them with > >>>>>>>>> ENDBR64 opcodes. When emulating the RET instruction, unwind shadow stack > >>>>>>>>> and reset IBT state machine. > >>>>>>>>> > >>>>>>>>> Signed-off-by: Yu-cheng Yu > > [...] > > >>>>>>>> > >>>>>>> > >>>>>>> For what it's worth, I think there is an alternative. If you all > >>>>>>> (userspace people, etc) can come up with a credible way for a user > >>>>>>> program to statically declare that it doesn't need vsyscalls, then we > >>>>>>> could make SHSTK depend on *that*, and we could avoid this mess. This > >>>>>>> breaks orthogonality, but it's probably a decent outcome. > >>>>>>> > >>>>>> > >>>>>> Would an arch_prctl(DISABLE_VSYSCALL) work? The kernel then sets a > >>>>>> thread flag, and in emulate_vsyscall(), checks the flag. > >>>>>> > >>>>>> When CET is enabled, ld-linux will do DISABLE_VSYSCALL. > >>>>>> > >>>>>> How is that? > >>>>> > >>>>> Backwards, no? Presumably vsyscall needs to be disabled before or > >>>>> concurrently with CET being enabled, not after. > >>>>> > >>>>> I think the solution of making vsyscall emulation work correctly with > >>>>> CET is going to be better and possibly more straightforward. > >>>>> > >>>> > >>>> We can do > >>>> > >>>> 1. Add ARCH_X86_DISABLE_VSYSCALL to disable the vsyscall page. > >>>> 2. If CPU supports CET and the program is CET enabled: > >>>> a. Disable the vsyscall page. > >>>> b. Pass control to user. > >>>> c. Enable the vsyscall page when ARCH_X86_CET_DISABLE is called. > >>>> > >>>> So when control is passed from kernel to user, the vsyscall page is > >>>> disabled if the program > >>>> is CET enabled. > >>> > >>> Let me say this one more time: > >>> > >>> If we have a per-process vsyscall disable control and a per-process > >>> CET control, we are going to keep those settings orthogonal. I'm > >>> willing to entertain an option in which enabling SHSTK without also > >>> disabling vsyscalls is disallowed, We are *not* going to have any CET > >>> flags magically disable vsyscalls, though, and we are not going to > >>> have a situation where disabling vsyscalls on process startup requires > >>> enabling SHSTK. > >>> > >>> Any possible static vsyscall controls (and CET controls, for that > >>> matter) also need to come with some explanation of whether they are > >>> properties set on the ELF loader, the ELF program being loaded, or > >>> both. And this explanation needs to cover what happens when old > >>> binaries link against new libc versions and vice versa. A new > >>> CET-enabled binary linked against old libc running on a new kernel > >>> that is expected to work on a non-CET CPU MUST work on a CET CPU, too. > >>> > >>> Right now, literally the only thing preventing vsyscall emulation from > >>> coexisting with SHSTK is that the implementation eeds work. > >>> > >>> So your proposal is rejected. Sorry. > >>> > >> I think, even with shadow stack/ibt enabled, we can still allow XONLY > >> without too much mess. > >> > >> What about this? > >> > >> Thanks, > >> Yu-cheng > >> > >> ====== > >> > >> diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c > >> b/arch/x86/entry/vsyscall/vsyscall_64.c > >> index 8b0b32ac7791..d39da0a15521 100644 > >> --- a/arch/x86/entry/vsyscall/vsyscall_64.c > >> +++ b/arch/x86/entry/vsyscall/vsyscall_64.c > >> @@ -48,16 +48,16 @@ > >> static enum { EMULATE, XONLY, NONE } vsyscall_mode __ro_after_init = > >> #ifdef CONFIG_LEGACY_VSYSCALL_NONE > >> NONE; > >> -#elif defined(CONFIG_LEGACY_VSYSCALL_XONLY) > >> +#elif defined(CONFIG_LEGACY_VSYSCALL_XONLY) || defined(CONFIG_X86_CET) > >> XONLY; > >> -#else > >> +#else > >> EMULATE; > >> #endif > > > > I don't get it. > > > > First, you can't do any of this based on config -- it must be runtime. > > > > Second, and more importantly, I don't see how XONLY helps at all. The > > (non-executable) text that's exposed to user code in EMULATE mode is > > trivial to get right with CET -- your code already handles it. It's > > the emulation code (that runs identically in EMULATE and XONLY mode) > > that's tricky. > > > > Hi, > > There has been some ambiguity in my previous proposals. To make things > clear, I created a patch for arch_prctl(VSYSCALL_CTL), which controls > the TIF_VSYSCALL_DISABLE flag. It is entirely orthogonal to shadow > stack or IBT. On top of the patch, we can do SET_PERSONALITY2() to > disable vsyscall, e.g. NAK. Let me try explaining again. > > ====== > diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h > index 0e1be2a13359..c730ff00bc62 100644 > --- a/arch/x86/include/asm/elf.h > +++ b/arch/x86/include/asm/elf.h > @@ -394,6 +394,19 @@ struct arch_elf_state { > .gnu_property = 0, \ > } > > +#define SET_PERSONALITY2(ex, state) \ > +do { \ > + unsigned int has_cet; \ > + \ > + has_cet = GNU_PROPERTY_X86_FEATURE_1_SHSTK | \ > + GNU_PROPERTY_X86_FEATURE_1_IBT; \ > + \ > + if ((state)->gnu_property & has_cet) \ > + set_thread_flag(TIF_VSYSCALL_DISABLE); \ > + \ > + SET_PERSONALITY(ex); \ > +} while (0) > + This is not what "orthogonal" means. If the bits were orthogonal, the logic would be: if (gnu_property & DISABLE_VSYSCALL) disable vsyscall; if (gnu_property & SHSTK) enable SHSTK; if (gnu_property & IBT); enable IBT; and, if necessarily (although I still think it would be preferable not to do this): if ((gnu_property & (DISABLE_VSYSCALL | SHSTK)) == SHSTK) return -EINVAL; As far as I'm concerned, you have two choices: a) Make SHSTK work *correctly* with vsyscall emulation. b) Add a high quality mechanism to disable vsyscall emulation and make SHSTK depend on that. As far as I'm concerned, (a) is preferable. Ideally we'd get (a) *and* a high quality vsyscall emulation disable mechanism with no dependencies. > diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c > b/arch/x86/entry/vsyscall/vsyscall_64.c > index 44c33103a955..fe8f3db6d21b 100644 > --- a/arch/x86/entry/vsyscall/vsyscall_64.c > +++ b/arch/x86/entry/vsyscall/vsyscall_64.c > @@ -127,6 +127,9 @@ bool emulate_vsyscall(unsigned long error_code, > long ret; > unsigned long orig_dx; > > + if (test_thread_flag(TIF_VSYSCALL_DISABLE)) > + return false; > + This needs to be per-mm, not per-thread. There's a patch floating around that gets us about a quarter of the way there. I'm not convinced that CET should wait for this to finish.