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 21:34:05 +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 13:21 -0800, H.J. Lu wrote:
> > > 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
> 
> Not necessarily.  The problem will show up only in a CET enabled
> environment since build/test setup may not be on a CET capable
> hardware.

Well, I'm not sure of the details of distro testing, but there are
plenty of TGL and later systems out there today. With kernel support, 
I'm thinking these types of problems couldn't lurk for years like they
have.

> 
> > 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?
> 
> Don't enable CET in glibc until we can validate CET functionality.

Can you elaborate on what you mean by this? Not upstream glibc CET
support? Or have users not enable it? If the latter, how would they
know about all these problems.

And what is wrong with the cleanest option, number 1? The ABI document 
can be updated.