linux-kernel - Re: [RFC 37/37] fs/binfmt_elf: Block old shstk elf bit

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:   Mon, 7 Nov 2022 17:37:14 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "fweimer@...hat.com" <fweimer@...hat.com>
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>,
        "Yu, Yu-cheng" <yu-cheng.yu@...el.com>,
        "Eranian, Stephane" <eranian@...gle.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "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>,
        "jamorris@...ux.microsoft.com" <jamorris@...ux.microsoft.com>,
        "arnd@...db.de" <arnd@...db.de>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "pavel@....cz" <pavel@....cz>,
        "mike.kravetz@...cle.com" <mike.kravetz@...cle.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "rppt@...nel.org" <rppt@...nel.org>,
        "john.allen@....com" <john.allen@....com>,
        "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>
Subject: Re: [RFC 37/37] fs/binfmt_elf: Block old shstk elf bit

On Mon, 2022-11-07 at 17:55 +0100, Florian Weimer wrote:
> * Rick P. Edgecombe:
> 
> > On Sun, 2022-11-06 at 10:33 +0100, Florian Weimer wrote:
> > > * H. J. Lu:
> > > 
> > > > This change doesn't make a binary CET compatible.  It just
> > > > requires
> > > > that the toolchain must be updated and all binaries have to be
> > > > recompiled with the new toolchain to enable CET.  It doesn't
> > > > solve
> > > > any
> > > > issue which can't be solved by not updating glibc.
> > > 
> > > Right, and it doesn't even address the library case (the kernel
> > > would
> > > have to hook into mmap for that).  The kernel shouldn't do this.
> > 
> > Shadow stack shouldn't enable as a result of loading a library, if
> > that's what you mean.
> 
> It's the opposite—loading incompatible libraries needs to disable
> shadow
> stack (or ideally, not enable it in the first place).

The glibc changes I have been using would not have enabled shadow stack
in the first place unless the execing binary has the elf bit. So the
binary would run as if shadow stack was not enabled in the kernel and
there should be nothing to disable when an incompatible binary is
loaded. Glibc will have to detect this and act accordingly because not
all kernels will have shadow stack configured.

>   Technically, I
> think most incompatible code resides in libraries, so this kernel
> change
> achieves nothing besides punishing early implementations of the
> published-as-finalized x86-64 ABI.

It's under the assumption that not breaking things is more important
than having shadow stack enabled. So it is not intended as a punishment
for users at all, rather the opposite.

I'm not sure how much the spec mandates things by the letter of it, but
in any case things have gone wrong in the real world. I am very open to
discussion here. I only went this way as a last resort because I didn't
hear back on the last thread.