Re: [RFC][PATCH 21/24] x86/entry: Disable stack-protector for IST entry C handlers

[Segher Boessenkool <segher@kernel.crashing.org>]

On Thu, Nov 26, 2020 at 07:40:10AM +0100, Ard Biesheuvel wrote:
> On Thu, 26 Nov 2020 at 00:03, Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> > On Wed, Nov 25, 2020 at 11:56:40AM -0800, Kees Cook wrote:
> > > On Sat, Nov 14, 2020 at 11:20:17AM +0100, Ard Biesheuvel wrote:
> > > > In spite of the apparent difference of opinion here, there are two
> > > > irrefutable facts about __attribute__((optimize)) on GCC that can only
> > > > lead to the conclusion that we must never use it in Linux:
> > > > - the GCC developers refuse to rigorously define its behavior, so we
> > > > don't know what it actually does;
> >
> > This is because it isn't clear at all what it *should* do, for some
> > options.  For others it is obvious, and it works just fine for those.
> 
> The problem is that the distinction of some vs. others is not
> documented, and may change between architectures or GCC versions.

And obvious is still obvious.

> > (And we do not rigorously define the behaviour of almost *anything*, not
> > in the user manual anyway!)
> >
> > The interface has huge usability problems.  We want to wean people off
> > of using this attribute.  But claiming all kinds of FUD about it is a
> > disservice to users: it works fine for where it does work, there is no
> > reason for people to hurriedly change their code (or change it at all).
> 
> What do you mean by all kinds of FUD? The kind of FUD appearing on the
> GCC wiki? I'll quote it again here for everyone's convenience.

<snip>

No, saying "ohnoes this feature (that always worked fine for many
purposes) is so broken that it is super dangerous to keep using it even
a minute longer".  _That_ FUD.

> The reason we have to change code in the kernel is because it actually
> breaks stuff.

That makes sense.  Then please write *that*?  :-)

> For instance, functions using __attribute__((optimize))
> to disable GCSE are suddenly compiled with or without stack protector
> checks or frame pointers, even though the opposite option is set at
> the compilation unit level.

Not that disabling GCSE makes much sense anyway (there are other passes
that do many of the same things, for example).  So why was this added?
To avoid some bug on some older compiler version?

> I am not disputing that __attribute__((optimize)) is highly useful in
> some cases, I am just arguing that such cases don't exist in a Linux
> kernel running on a production system.

And I am saying that before you can remove something, you probably
should look at why it was added in the first place, and see if you need
a replacement for that, etc.  Just destroying stuff you do not agree
with is iconoclasm.


Segher