linux-kernel - Re: [PATCH v4 07/39] x86: Add user control-protection fault handler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 21 Dec 2022 21:42:50 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "bp@...en8.de" <bp@...en8.de>
CC:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "kcc@...gle.com" <kcc@...gle.com>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "Lutomirski, Andy" <luto@...nel.org>,
        "nadav.amit@...il.com" <nadav.amit@...il.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "Schimpe, Christina" <christina.schimpe@...el.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "corbet@....net" <corbet@....net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dethoma@...rosoft.com" <dethoma@...rosoft.com>,
        "jannh@...gle.com" <jannh@...gle.com>,
        "x86@...nel.org" <x86@...nel.org>, "pavel@....cz" <pavel@....cz>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        "rppt@...nel.org" <rppt@...nel.org>,
        "jamorris@...ux.microsoft.com" <jamorris@...ux.microsoft.com>,
        "arnd@...db.de" <arnd@...db.de>,
        "john.allen@....com" <john.allen@....com>,
        "bsingharora@...il.com" <bsingharora@...il.com>,
        "mike.kravetz@...cle.com" <mike.kravetz@...cle.com>,
        "oleg@...hat.com" <oleg@...hat.com>,
        "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
        "Yu, Yu-cheng" <yu-cheng.yu@...el.com>,
        "gorcunov@...il.com" <gorcunov@...il.com>,
        "fweimer@...hat.com" <fweimer@...hat.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "hpa@...or.com" <hpa@...or.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "mtk.manpages@...il.com" <mtk.manpages@...il.com>,
        "hjl.tools@...il.com" <hjl.tools@...il.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "Syromiatnikov, Eugene" <esyr@...hat.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "Yang, Weijiang" <weijiang.yang@...el.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "Eranian, Stephane" <eranian@...gle.com>
Subject: Re: [PATCH v4 07/39] x86: Add user control-protection fault handler

On Wed, 2022-12-21 at 11:41 +0100, Borislav Petkov wrote:
> On Wed, Dec 21, 2022 at 12:37:51AM +0000, Edgecombe, Rick P wrote:
> > You mean having separate paths for kernel IBT and user shadow stack
> > that compile out? I guess it could just all be in place if
> > CONFIG_X86_CET is in place.
> > 
> > I don't know, I thought it was relatively clean, but I can remove
> > it.
> 
> Yeah, I'm wondering if we really need the ifdeffery. I always
> question
> ifdeffery because it is a) ugly, b) a mess to deal with and having it
> is
> not really worth it. Yeah, we save a couple of KBs, big deal.
> 
> What would practically happen is, shadow stack will be default-
> enabled
> on the majority of kernels out there - distro ones - so it will be
> enabled practically everywhere.
> 
> And it'll be off only in some self-built kernels which are the very
> small minority.
> 
> And how much are the space savings with the whole set applied, with
> and
> without the Kconfig item enabled? Probably only a couple of KBs.

Oh, you mean the whole Kconfig thing. Yea, I mean I see the point about
typical configs. But at least CONFIG_X86_CET seems consistent with
CONFIG_INTEL_TDX_GUEST, CONFIG_IOMMU_SVA, etc.

What about moving it out of traps.c to a cet.c, like
exc_vmm_communication for CONFIG_AMD_MEM_ENCRT? Then the inclusion
logic lives in the build files, instead of an ifdef.

> 
> And if so, I'm thinking we could at least make the traps.c stuff
> unconditional - it'll be there but won't run. Unless we get some
> weird
> #CP but it'll be caught by do_unexpected_cp().
> 
> And you have feature tests everywhere so it's not like it'll get
> "misused".
> 
> And when you do that, you'll have everything a lot simpler, a lot
> less
> Kconfig items to build-test and all good.
> 
> Right?
> 
> Or am I completely way off into the weeds here and am missing an
> important aspect...?
> 

One aspect that has come up a couple of times, is how closely related
all these CET features are (or aren't). Shadow stack and IBT are mostly
separate, but do share an xfeature and an exception type. Similarly for
supervisor and user mode support for either of the CET features. So
maybe that is what is unusual here. There are some aspects that make
them look like separate features, which leads people to think they
should be separate in the code. But actually separating them leads to
excess ifdefery.

To me, putting the whole handler in even if there are no CET features
seems like too much. Leaving it in unconditionally is apparently also
inconsistent with some of the previous traps.c decisions. So I'd leave
CONFIG_X86_CET at least and it can help anyone building super stripped
down kernels. But I'm ok with whatever people think.