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

[Kees Cook <keescook@chromium.org>]

On Sat, Nov 14, 2020 at 11:20:17AM +0100, Ard Biesheuvel wrote:
> On Sat, 14 Nov 2020 at 02:59, Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > On Sat, Nov 14, 2020 at 1:27 AM Segher Boessenkool
> > <segher@kernel.crashing.org> wrote:
> > >
> > > But you cannot limit yourself to the greatest common denominator: the
> > > kernel wants to use many features only available on newer compiler
> > > versions, too; this is no different.
> >
> > What we do is conditionally enable both new and differentiating
> > features. We don't break GCC or LLVM just because the other introduces
> > a new shiny feature, nor we break builds with old compilers (except
> > when raising the minimum supported version).
> >
> > That is why we need a level of indirection in things like attributes
> > nowadays, and why patches like the above are not ideal anymore
> > (regardless of which attribute we are talking about).
> >
> 
> 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;
> - it has been observed to nullify unrelated command line arguments in
> unexpected and undocumented ways.
> 
> So it does not matter whether you call that quirky or something else,
> there is no way we can make meaningful use of it, and therefore,
> abstracting or parameterizing any of its uses should be avoided as
> well.

Perhaps it's worth adding this to CodingStyle or deprecated.rst?

-- 
Kees Cook