[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgP5mk3poVeejw16Asbid0ghDt4okHnWaWKLBkRhQntRA@mail.gmail.com>
Date: Mon, 14 Nov 2022 18:01:46 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "keescook@...omium.org" <keescook@...omium.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"fweimer@...hat.com" <fweimer@...hat.com>,
"hjl.tools@...il.com" <hjl.tools@...il.com>,
"x86@...nel.org" <x86@...nel.org>
Subject: Re: CET shadow stack app compatibility
On Mon, Nov 14, 2022 at 3:15 PM Edgecombe, Rick P
<rick.p.edgecombe@...el.com> wrote:
>
> I would like to make this go smoother all around by having the kernel
> detect the existing elf bit and refuse to enable CET for these
> applications, like this[1].
Honestly, I don't want to preemptively say 'this won't work".
That said, once CET is enabled in the kernel, and it turns out that
people complain that it breaks existing binaries, at that point I
guess it gets disabled again. Possibly at that point using something
like your suggested patch. But I'm not doing it until actual problems
appear, and until we actually have this code in the kernel.
I'm disgusted by glibc being willing to just upgrade and break
existing binaries and take the "you shouldn't upgrade glibc if you
have old binaries" approach.
But hey, I guess that's part for the course for glibc, and there's
nothing I can do about that.
But yes, once people complain, I'll just make sure that old binaries
continue to work, and at that point the glibc and tooling people will
presumably have to fix their broken situation to get CET at all.
Because no, the kernel doesn't enable CET if it breaks binaries.
That's how we roll.
Linus
Powered by blists - more mailing lists