linux-kernel - Re: [PATCH v3 24/37] x86: Introduce userspace API for CET enabling

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]

Message-ID: <049eb42bdcb72731af34cd9de4ad04a770b2dc7a.camel@intel.com>
Date:   Tue, 15 Nov 2022 20:55:04 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "peterz@...radead.org" <peterz@...radead.org>
CC:     "mark.rutland@....com" <mark.rutland@....com>,
        "bsingharora@...il.com" <bsingharora@...il.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "Syromiatnikov, Eugene" <esyr@...hat.com>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "Eranian, Stephane" <eranian@...gle.com>,
        "will@...nel.org" <will@...nel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "fweimer@...hat.com" <fweimer@...hat.com>,
        "nadav.amit@...il.com" <nadav.amit@...il.com>,
        "jannh@...gle.com" <jannh@...gle.com>,
        "dethoma@...rosoft.com" <dethoma@...rosoft.com>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "kcc@...gle.com" <kcc@...gle.com>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "bp@...en8.de" <bp@...en8.de>, "oleg@...hat.com" <oleg@...hat.com>,
        "hjl.tools@...il.com" <hjl.tools@...il.com>,
        "Yang, Weijiang" <weijiang.yang@...el.com>,
        "Lutomirski, Andy" <luto@...nel.org>,
        "pavel@....cz" <pavel@....cz>, "arnd@...db.de" <arnd@...db.de>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mike.kravetz@...cle.com" <mike.kravetz@...cle.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "jamorris@...ux.microsoft.com" <jamorris@...ux.microsoft.com>,
        "john.allen@....com" <john.allen@....com>,
        "rppt@...nel.org" <rppt@...nel.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        "corbet@....net" <corbet@....net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        "gorcunov@...il.com" <gorcunov@...il.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [PATCH v3 24/37] x86: Introduce userspace API for CET enabling

On Tue, 2022-11-15 at 14:03 +0100, Peter Zijlstra wrote:
> On Tue, Nov 15, 2022 at 01:26:23PM +0100, Peter Zijlstra wrote:
> > On Fri, Nov 04, 2022 at 03:35:51PM -0700, Rick Edgecombe wrote:
> > > From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
> > > 
> > > Add three new arch_prctl() handles:
> > > 
> > >   - ARCH_CET_ENABLE/DISABLE enables or disables the specified
> > >     feature. Returns 0 on success or an error.
> > > 
> > >   - ARCH_CET_LOCK prevents future disabling or enabling of the
> > >     specified feature. Returns 0 on success or an error
> > > 
> > > The features are handled per-thread and inherited over
> > > fork(2)/clone(2),
> > > but reset on exec().
> > > 
> > > This is preparation patch. It does not implement any features.
> > 
> > Urgh... so much for sharing with other architectures I suppose :/
> > 
> > The ARM64 BTI thing is very similar to IBT (except I think their
> > approach to the legacy bitmap is much saner).
> > 
> > Given that IBT isn't supported and needs the whole legacy bitmap
> > mess,
> > do we really want to call this CET ? Why not just make a Shadow
> > Stack
> > API and tackle IBT independently.
> 
> On that; ARM64 exposes PROT_BTI (to be used by mprotect()) and have
> an
> ELF_ARM64_BTI note for the loader to bootstrap things.
> 
> We could co-opt that same interface and instead of flipping actual
> PTE
> bits, have this thing manage the legacy bitmap -- basically have the
> legacy bitmap function as an external PTE bit array (in inverse).
> 
> Basically, have every page mapped PROT_EXEC set the bit in the legacy
> bitmap while every page mapped PROT_EXEC|PROT_BTI will have the
> legacy
> bitmap bit to 0.
> 
> And as long as there is a single 0 in the bitmap, the feature is
> enabled.
> 
> (obviously we can delay allocating the bitmap until the first
> PROT_EXEC
> mapping that lacks PROT_BTI)

This is an interesting idea. I'll have to think a little more on it.

One non-impossible issue would be setting IBT in the MSR late. Each
thread would have to be interrupted and have it set, while no new
threads are created. Maybe this is easy and I just don't know how to do
it.

The other thing is there would be overhead compared to an IBT
implementation with a separate interface from BTI. Would have to look
at the tradeoffs.