linux-kernel - Re: [PATCH v2 04/39] x86/cpufeatures: Enable CET CR4 bit for shadow stack

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: <da26db09-ae80-f076-388f-9d5884f67b23@citrix.com>
Date:   Wed, 5 Oct 2022 00:55:28 +0000
From:   Andrew Cooper <Andrew.Cooper3@...rix.com>
To:     Rick Edgecombe <rick.p.edgecombe@...el.com>,
        "x86@...nel.org" <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-kernel@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "linux-api@...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>,
        Peter Zijlstra <peterz@...radead.org>,
        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>,
        "joao.moreira@...el.com" <joao.moreira@...el.com>,
        John Allen <john.allen@....com>,
        "kcc@...gle.com" <kcc@...gle.com>,
        "eranian@...gle.com" <eranian@...gle.com>,
        "rppt@...nel.org" <rppt@...nel.org>,
        "jamorris@...ux.microsoft.com" <jamorris@...ux.microsoft.com>,
        "dethoma@...rosoft.com" <dethoma@...rosoft.com>,
        Andrew Cooper <Andrew.Cooper3@...rix.com>
CC:     Yu-cheng Yu <yu-cheng.yu@...el.com>
Subject: Re: [PATCH v2 04/39] x86/cpufeatures: Enable CET CR4 bit for shadow
 stack

On 29/09/2022 23:29, Rick Edgecombe wrote:
> From: Yu-cheng Yu <yu-cheng.yu@...el.com>
>
> Utilizing CET features requires a CR4 bit to be enabled as well as bits
> to be set in CET MSRs. Setting the CR4 bit does two things:
>  1. Enables the usage of WRUSS instruction, which the kernel can use to
>     write to userspace shadow stacks.
>  2. Allows those individual aspects of CET to be enabled later via the MSR.
>  3. Allows CET to be enabled in guests

Point 1, yes, but the others, not really.  Guests aren't interesting
because host CR4 != guest CR4.

CET is a tangled mess of control bits.  The MSRs can be configured and
context switched independently CR4.

The 4 main sub-feature enablement conditions are CR4.CET &&
MSR_{U,S}_CET.{SHSTK,ENDBR}_EN.

The WRUSS instruction is keyed on CR4.CET alone.  This is because
CR4.CET is the paging control which changes the interpretation of
R/O+Dirty, and is a prerequisite for any shstk memory accesses.  Most
other shstk instructions have finer grain enablement conditions.

I'd suggest simplifying the commit message massively, to say that
CR4.CET is a prerequisite for all CET operation, so extend setup_cet()
to enable it for user shadow stacks.

It hopefully goes without saying that you cannot do an equivalent piece
of code for supervisor shadow stacks.  If you try, you'll discover that
everything works fine until you try returning from the function which
activated the second of CR4.CET and MSR_S_CET.SHSTK_EN, and the valid
content on the shadow stack underflows.

~Andrew

P.S. There's a fun infoleak.

Userspace can probe for kernel shstk enablement using fault analysis on
the SETSSBUSY instruction.  It takes #UD for !CR4.CET ||
!MSR_S_CET.SHSTK_EN, and then #GP for CPL !=0.