linux-kernel - RE: [PATCH v3 35/37] x86/cet: Add PTRACE interface for CET

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CY4PR11MB2005AD47BA1D97BC1A96A769F9069@CY4PR11MB2005.namprd11.prod.outlook.com>
Date:   Thu, 17 Nov 2022 12:25:16 +0000
From:   "Schimpe, Christina" <christina.schimpe@...el.com>
To:     "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
        "peterz@...radead.org" <peterz@...radead.org>
CC:     "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>,
        "Yu, Yu-cheng" <yu-cheng.yu@...el.com>,
        "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>,
        "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>,
        "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 35/37] x86/cet: Add PTRACE interface for CET

> + Christina
> 
> On Tue, 2022-11-15 at 15:43 +0100, Peter Zijlstra wrote:
> > On Fri, Nov 04, 2022 at 03:36:02PM -0700, Rick Edgecombe wrote:
> > > From: Yu-cheng Yu <yu-cheng.yu@...el.com>
> > >
> > > Some applications (like GDB and CRIU) would like to tweak CET state
> > > via ptrace. This allows for existing functionality to continue to
> > > work for seized CET applications. Provide an interface based on the
> > > xsave buffer format of CET, but filter unneeded states to make the
> > > kernel’s job easier.
> > >
> > > There is already ptrace functionality for accessing xstate, but this
> > > does not include supervisor xfeatures. So there is not a completely
> > > clear place for where to put the CET state. Adding it to the user
> > > xfeatures regset would complicate that code, as it currently shares
> > > logic with signals which should not have supervisor features.
> > >
> > > Don’t add a general supervisor xfeature regset like the user one,
> > > because it is better to maintain flexibility for other supervisor
> > > xfeatures to define their own interface. For example, an xfeature
> > > may decide not to expose all of it’s state to userspace. A lot of
> > > enum values remain to be used, so just put it in dedicated CET
> > > regset.
> > >
> > > The only downside to not having a generic supervisor xfeature
> > > regset, is that apps need to be enlightened of any new supervisor
> > > xfeature exposed this way (i.e. they can’t try to have generic
> > > save/restore logic). But maybe that is a good thing, because they
> > > have to think through each new xfeature instead of encountering
> > > issues when new a new supervisor xfeature was added.
> >
> > Per this argument this should not use the CET XSAVE format and CET
> > name at all, because that conflates the situation vs IBT. Enabling
> > that might not want to follow this precedent.
> 
> Hmm, we definitely need to be able to set the SSP. Christina, does GDB need
> anything else? I thought maybe toggling SHSTK_EN?

In addition to the SSP, we want to write the CET state. For instance for inferior calls,
we want to reset the IBT bits.
However, we won't write states that are disallowed by HW.
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928