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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 15 Nov 2022 15:43:37 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Rick Edgecombe <rick.p.edgecombe@...el.com>
Cc:     x86@...nel.org, "H . Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-mm@...ck.org,
        linux-arch@...r.kernel.org, linux-api@...r.kernel.org,
        Arnd Bergmann <arnd@...db.de>,
        Andy Lutomirski <luto@...nel.org>,
        Balbir Singh <bsingharora@...il.com>,
        Borislav Petkov <bp@...en8.de>,
        Cyrill Gorcunov <gorcunov@...il.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Eugene Syromiatnikov <esyr@...hat.com>,
        Florian Weimer <fweimer@...hat.com>,
        "H . J . Lu" <hjl.tools@...il.com>, Jann Horn <jannh@...gle.com>,
        Jonathan Corbet <corbet@....net>,
        Kees Cook <keescook@...omium.org>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Nadav Amit <nadav.amit@...il.com>,
        Oleg Nesterov <oleg@...hat.com>, Pavel Machek <pavel@....cz>,
        Randy Dunlap <rdunlap@...radead.org>,
        "Ravi V . Shankar" <ravi.v.shankar@...el.com>,
        Weijiang Yang <weijiang.yang@...el.com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        John Allen <john.allen@....com>, kcc@...gle.com,
        eranian@...gle.com, rppt@...nel.org, jamorris@...ux.microsoft.com,
        dethoma@...rosoft.com, akpm@...ux-foundation.org,
        Yu-cheng Yu <yu-cheng.yu@...el.com>
Subject: Re: [PATCH v3 35/37] x86/cet: Add PTRACE interface for CET

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.

> By adding a CET regset, it also has the effect of including the CET state
> in a core dump, which could be useful for debugging.
> 
> Inside the setter CET regset, filter out invalid state. Today this
> includes states disallowed by the HW and states involving Indirect Branch
> Tracking which the kernel does not currently support for usersapce.
> 
> So this leaves three pieces of data that can be set, shadow stack
> enablement, WRSS enablement and the shadow stack pointer. It is worth
> noting that this is separate than enabling shadow stack via the
> arch_prctl()s.

Does this validate the SSP, when set, points to an actual valid SS page?