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: <CAMe9rOr1XpnisqWHh6C6Wi6tUAu5avhbKb_7E7ZpN_eMkktTww@mail.gmail.com>
Date:   Mon, 7 Nov 2022 13:47:56 -0800
From:   "H.J. Lu" <hjl.tools@...il.com>
To:     "Edgecombe, Rick P" <rick.p.edgecombe@...el.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, Nov 7, 2022 at 1:34 PM Edgecombe, Rick P
<rick.p.edgecombe@...el.com> wrote:
>
> 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.

If this is the case, we would have nothing to worry about since the CET
enabled applications won't pass validation if they aren't CET compatible.

> >
> > > 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.

The current glibc doesn't support CET.  To enable CET in an application,
one should validate it together with the CET enabled glibc under the CET
enabled kernel on a CET capable machine.

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

It doesn't help resolve any issues.

-- 
H.J.