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]
Message-ID: <73b8f726c424db1af1c10a48e101bf74703a186a.camel@intel.com>
Date:   Mon, 7 Nov 2022 21:10:52 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "hjl.tools@...il.com" <hjl.tools@...il.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>,
        "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>,
        "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>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "pavel@....cz" <pavel@....cz>,
        "mike.kravetz@...cle.com" <mike.kravetz@...cle.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "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>
Subject: Re: [RFC 37/37] fs/binfmt_elf: Block old shstk elf bit

On Mon, 2022-11-07 at 11:10 -0800, H.J. Lu wrote:
> On Mon, Nov 7, 2022 at 9:47 AM Edgecombe, Rick P
> <rick.p.edgecombe@...el.com> wrote:
> > 
> > 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.
> 
> Some applications and libraries are compiled with -fcf-protection,
> but
> they manipulate the stack in such a way that they aren't compatible
> with the shadow stack.   However, if the build/test setup doesn't
> support
> shadow stack, it is impossible to validate.
> 

When we have everything in place, the problems would be much more
obvious when distros started turning it on. But we can't turn it on as
planned without breaking things for existing binaries. We can have both
by:
1. Choosing a new bit, adding it to the tools, and never supporting the
old bit in glibc.
2. Providing the option to have the kernel block the old bit, so
upgraded users can decide what experience they would like. Then distros
can find the problems and adjust their packages. I'm starting to think
a default off sysctl toggle might be better than a Kconfig.
3. Any other ideas?