Still fixing the Stack Clash fix

[Posted July 5, 2017 by corbet]

As was noted last week, the story of the Stack Clash bug continues to play out. In this week's episode, Ben Hutchings reported a couple of new regressions caused by the fixes merged into the 4.12 kernel and backported to the stable trees. These have led to a new series of fixes — and some developers questioning the entire effort.

The first regression happens with Rust programs on the PowerPC architecture. It seems that Rust adds its own guard page to the stack, and that page prevents the stack from expanding as a result of an interaction with the relatively large (16MB) stack gap used on that architecture. The fix in this case is likely to involve explicitly allowing the stack to expand over a PROT_NONE mapping (a guard page, essentially) that stands in its way.

The other problem affects Java code running within LibreOffice on 32-bit systems. The cause here would appear to be an old workaround for a conflict with the venerable "Exec Shield" mechanism. This one will be harder to fix; it may require making the stack gap adjustable on a per-process basis, then telling any distributors still shipping 32-bit versions to add a special wrapper for LibreOffice (and possibly other Java-using programs) shrinking the gap.

All this has led Andy Lutomirski to complain that all of the stack-gap work is a regression-causing ABI change that shouldn't be happening. "We all realize that this issue is a longstanding *GCC* bug, but we're acting like it's a Big Deal (tm) kernel bug that Must Be Fixed (tm) and therefore is allowed to break ABI." He suggested removing the changes entirely and rethinking the whole problem in terms of hardening the kernel while waiting for the compiler to be fixed. An about-face of this magnitude seems unlikely at this point but, if the regressions continue to pile up, attitudes could yet change.

(Log in to post comments)

Still fixing the Stack Clash fix

Posted Jul 6, 2017 15:14 UTC (Thu) by jhoblitt (subscriber, #77733) [Link]

I agree with Lutomirski; breaking existing binaries (especially for a not-an-actual security fix) seems fundamentally against long standing kernel policy.

Still fixing the Stack Clash fix

Posted Jul 6, 2017 21:56 UTC (Thu) by wtarreau (subscriber, #51152) [Link]

we're still trying to find the best way to protect applications while not changing their behaviour if not needed. This is subtle. At least there are some hints because broken applications are those making use of workarounds that can be detected. What's still uncertain is whether these workarounds are exhaustive.

Still fixing the Stack Clash fix

Posted Jul 7, 2017 14:28 UTC (Fri) by deater (subscriber, #11746) [Link]

> breaking existing binaries (especially for a not-an-
> actual security fix) seems fundamentally against
> long standing kernel policy.

It sometimes seems hit or miss how quickly an ABI fix is made.

There was an ABI-breaking "security" fix in the perf_event subsystem that breaks the rr debugger. It was caught before 4.12, but not only was it not reverted before 4.12, the patch has managed to get applied to the various stable trees so now older kernels that used to work are broken.

Still fixing the Stack Clash fix

Posted Jul 10, 2017 14:44 UTC (Mon) by nix (subscriber, #2304) [Link]

Meanwhile the actual security fix of allowing perf to be disabled on kernels that don't need it remains out of tree :(