linux-kernel - Re: [PATCH v4 33/39] x86: Prevent 32 bit operations for 64 bit shstk tasks

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: <17e3d37afeab3821e8df3329603660c8f35e1ad1.camel@intel.com>
Date:   Thu, 15 Dec 2022 00:25:08 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "Lutomirski, Andy" <luto@...nel.org>
CC:     "bsingharora@...il.com" <bsingharora@...il.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "Syromiatnikov, Eugene" <esyr@...hat.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "Eranian, Stephane" <eranian@...gle.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.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>,
        "pavel@....cz" <pavel@....cz>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "jamorris@...ux.microsoft.com" <jamorris@...ux.microsoft.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "Schimpe, Christina" <christina.schimpe@...el.com>,
        "mike.kravetz@...cle.com" <mike.kravetz@...cle.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "Yang, Weijiang" <weijiang.yang@...el.com>,
        "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
        "john.allen@....com" <john.allen@....com>,
        "rppt@...nel.org" <rppt@...nel.org>,
        "mingo@...hat.com" <mingo@...hat.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 v4 33/39] x86: Prevent 32 bit operations for 64 bit shstk
 tasks

On Sun, 2022-12-04 at 12:51 -0800, Rick Edgecombe wrote:
> On Sat, 2022-12-03 at 14:49 -0800, Andy Lutomirski wrote:
> > On Fri, Dec 2, 2022 at 4:44 PM Rick Edgecombe
> > <rick.p.edgecombe@...el.com> wrote:
> > > 
> > > So since 32 bit is not easy to support, and there are likely not
> > > many
> > > users. More cleanly don't support 32 bit signals in a 64 bit
> > > address
> > > space by not allowing 32 bit ABI signal handlers when shadow
> > > stack
> > > is
> > > enabled. Do this by clearing any 32 bit ABI signal handlers when
> > > shadow
> > > stack is enabled, and disallow any further 32 bit ABI signal
> > > handlers.
> > > Also, return an error code for the clone operations when in a 32
> > > bit
> > > syscall.
> > > 
> > 
> > This seems unfortunate.  The result will be a highly
> > incomprehensible
> > crash.  Maybe instead deny enabling shadow stack in the first
> > place?
> > Or at least pr_warn_once if anything gets flushed.
> 
> Thanks for the suggestion! Denying seems much better, I'll change it.

Argh, the solution only work in the normal case where the first task
enables shadow stack. Otherwise the process could:
1. Have two threads without shadow stack
2. Enable shadow stack in thread 1
3. Register 32 bit handler from thread 2
4. Handle 32 bit signal in thread 1

For this amount of special case ugliness it should fix the whole
problem I think.

Trying to fix it up by adding 32 bit signal blocking state into struct
sighand_struct, so it would actually be per-process, spills this into
core code. I think it might not be the best solution. I'm not sure what
is yet.