grsecurity: Teardown of a Failed Linux LTS Spectre Fix [LWN.net]

This grsecurity blog entry looks at how an ineffective Spectre fix found its way into the stable kernel releases. If one looks past the advertising, it's a good summary of how the kernel processes can produce the wrong result. "Despite this warning, this code was merged into Thomas Gleixner's x86/tip tree verbatim, as can be seen here. Prior to merging the fix for 5.3-rc1, Linus Torvalds noticed the warning as seen on the LKML mailing list here and fixed it correctly. However, when the actual merge of the tree was performed, no mention was made of the correction to the fix, and with no specific commit mentioning the correction and fixing it alone, everyone else's processes that depended on cherry-picking specific commits ended up grabbing the bad warning-inducing change. As a further failure, instead of looking at Linus' correct fix (observable by checking out the master tree at the time), the approach seems to have been to naively silence the warning by simply swapping the order of the two lines".

to post comments

grsecurity: Teardown of a Failed Linux LTS Spectre Fix

Posted Sep 4, 2019 7:55 UTC (Wed) by zoobab (guest, #9945) [Link] (1 responses)

Where are the exploits? At least if exploits are published, it would be easier for kernel developers to test their kernels against such exploits, even integrating them in their CI/CD systems, if they have one.

And the Intel process and Linux patching was a shame, as pointed out by the OpenBSD developers:

https://bsd.slashdot.org/story/18/01/08/0533237/openbsds-...

grsecurity: Teardown of a Failed Linux LTS Spectre Fix

Posted Sep 5, 2019 7:10 UTC (Thu) by ssmith32 (subscriber, #72404) [Link]

Come on' !
At least link to the LWN article about how badly it was handled ;).

Not some clickbaity article that pulls one squote, and leaves it at that ..

https://lwn.net/Articles/743363/

grsecurity: Teardown of a Failed Linux LTS Spectre Fix

Posted Sep 4, 2019 9:37 UTC (Wed) by niner (guest, #26151) [Link] (8 responses)

So all this started when the compiler threw a warning about something that shouldn't be a problem in any way: "ISO C90 forbids mixed declarations and code". Why is the kernel compiled as C90? This restriction adds now value and constantly trips up developers. I don't think anybody would seriously expect the kernel to compile on a > 20 year old compiler that doesn't support C99.

grsecurity: Teardown of a Failed Linux LTS Spectre Fix

Posted Sep 4, 2019 11:20 UTC (Wed) by Wol (subscriber, #4433) [Link] (3 responses)

But IS IT compiled as C90?

Or is the compiler merely saying "if you feed this to a C90 compiler, it will fail ..."

Cheers,
Wol

grsecurity: Teardown of a Failed Linux LTS Spectre Fix

Posted Sep 4, 2019 11:28 UTC (Wed) by edomaur (subscriber, #14520) [Link]

It is. It's "C89+extensions".

grsecurity: Teardown of a Failed Linux LTS Spectre Fix

Posted Sep 4, 2019 12:48 UTC (Wed) by Paf (subscriber, #91811) [Link] (1 responses)

I’m pretty sure this restriction - which I do think adds value but I’m not going in that particular bikeshed - is part of all the C specs *since* C90, so... yeah. No issue with supporting old compilers. So if you want to get rid of it, you will have to go in that specific bikeshed. It says “standards committee” on the side, and I hear they keep dogs inside. Big, angry ones.

grsecurity: Teardown of a Failed Linux LTS Spectre Fix

Posted Sep 4, 2019 12:57 UTC (Wed) by niner (guest, #26151) [Link]

From gcc(1): "Warn when a declaration is found after a statement in a block. This construct, known from C++, was introduced with ISO C99 and is by default allowed in GCC. It is not supported by ISO C90."

So old C versions required all declarations to appear first in a block. C++ removed that requirement and the ISO standards committee backported that relaxation of the rules to C99.

grsecurity: Teardown of a Failed Linux LTS Spectre Fix

Posted Sep 4, 2019 20:35 UTC (Wed) by dezgeg (guest, #92243) [Link] (3 responses)

I belive the kernel intentionally doesn't use C99 because the ability to declare variables in the middle of a basic block is seen as a bad feature, see for example https://lkml.org/lkml/2012/4/12/18.

(I personally find that forcing declarations to happen at start of blocks is a great way to introduce uninitialized variable-related bugs).

grsecurity: Teardown of a Failed Linux LTS Spectre Fix

Posted Sep 4, 2019 22:04 UTC (Wed) by adobriyan (subscriber, #30858) [Link] (1 responses)

It is one of the silly rules indeed. Writing "for (int i = 0; i < N; i++)" is clearly superior.

grsecurity: Teardown of a Failed Linux LTS Spectre Fix

Posted Sep 9, 2019 23:14 UTC (Mon) by mangix (guest, #126006) [Link]

for (auto i...) is better still. But C++11.

grsecurity: Teardown of a Failed Linux LTS Spectre Fix

Posted Sep 8, 2019 6:06 UTC (Sun) by marcH (subscriber, #57642) [Link]

> (I personally find that forcing declarations to happen at start of blocks is a great way to introduce uninitialized variable-related bugs).

When you use a programming language designed for memory corruption, you want to make the most of it. /s

grsecurity: Teardown of a Failed Linux LTS Spectre Fix

Posted Sep 4, 2019 14:40 UTC (Wed) by ncultra (guest, #121511) [Link] (1 responses)

Wow, the LTS merge https://git.kernel.org/pub/scm/linux/kernel/git/stable/li... is *really* careless and shows an apparent lack of understanding the vulnerability.

grsecurity: Teardown of a Failed Linux LTS Spectre Fix

Posted Sep 4, 2019 15:54 UTC (Wed) by leromarinvit (subscriber, #56850) [Link]

Never mind the vulnerability, it should be obvious that assigning to a variable after its only use is probably not what you want. Even if you assumed throwing array_index_nospec() in after the access will magically protect you (not that I think Greg does), assigning to a variable that's never read again should raise suspicions.