On Thu, Nov 26, 2020 at 02:22:07PM -0600, Segher Boessenkool wrote:
> 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.
> 

In the context of _this_ thread -- newly applying the attribute to an
exception entry vector, it is about stopping new users who may not be
aware of the attribute's pitfalls.  You've got to admit that "quirky" is
comparatively mild language relative to what's in GCC's own wiki.

The breakage we've been trying to reverse/avoid isn't even about the
bugs alluded to in the wiki. It's an impedance mismatch in what users
are expecting the attribute to do and what it actually does, and it
would be good to add a mention of this in the documentation. Eg, in this
case the programmer expects stack protector to be disabled, and no other
effects. But the attribute will actually cause, eg -fstrict-aliasing to
be enabled for the function even though it was disabled on the command
line. Even outside of any bugs in the implementation of the attribute,
this has potential to subtly break kernel code in unexpected ways
because most users aren't aware of what the attribute really does.