Hacker News Reader

Comment by jaccarmac | Hacker News Reader

The kernels for Gentoo have been all over the place for the past few weeks. I'm running 4.12 at the moment, then the repos updated to 4.14, which wouldn't build for me, so I waited a week for genkernel to modernize. When I came back 4.14 had been marked unstable and 4.12 was masked, making 4.9 the latest supported kernel. Seems that whatever is happening is a Big Deal.

View on HN

Thats because Gentoo decided to switch on a new compile flag, then didn't bother to test that the kernel still boots:

https://lkml.org/lkml/2017/12/29/449

And, for reasons that are entirely unknown, the issue got worse due to one of the PTI patches (written by, and hence tentatively blamed on, yours truly). Presumably it caused some minor change in code generation causing GCC to go nuts.

FWIW, the compile flag that Gentoo enabled activates a seriously busted GCC feature, and I'm a bit surprised that Gentoo gets away with it in user code.

Is there anywhere to read up on the bustedness of the stack probing feature? (apart from the obvious incompatibility with trying to do that for kernel code).

Probing more than a page size below the current stack pointer is wrong. Probing more than a page size further when one's saved frame area, save area, locals area, and (maximum) calling parameters area do not amount to a page in total is also wrong.

For more on the considerations that underpin stack probing, see http://jdebp.eu./FGA/function-perilogues.html#StackProbes for starters.

Also, the probe does an unlocked RMW (or 0) instead of a read, which is slower but also wrong in a multithreaded application. The latter is what broke Go.

Is that because Go crams the thread stacks closely together and it probed into another thread's stack?

Regardless, it seems like RMW (or even just a store) should be fine as long as the stack pointer is adjusted before the probe.

Which compile flag is that? (I run Gentoo)

Edit: nevermind. It's the -fstack-check flag mentioned in the other comments.

The same compiler (mis-)feature was also the cause of spurious crashes in Go applications (diagnosed about a month ago: https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/). Linus's comment is fun:

  So yes, It's a terminally broken compiler from hell. I assume gentoo
  has applied some completely broken security patch to their compiler,
  turning said compiler into complete garbage.

Linus clarified later that he could reproduce on Fedora with the relevant build flag (-fstack-check). His initial assumption that this was caused by an out-of-tree patch specific to Gentoo was incorrect.

The patch to "fix" it is explicitly disabling -fstack-check for the kernel build. I believe that will go out in 4.14.11 (it is not in 4.14.10).

The flag is only enabled by default on hardened gentoo profiles. Non-hardened profiles has it disabled.

Reply on news.ycombinator.com