Linux 4.19 Kernel Getting STACKLEAK Feature

[phoronix]

Phoronix: Linux 4.19 Kernel Getting STACKLEAK Feature

Another security hardening measure coming to the Linux kernel is STACKLEAK...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-To-STACKLEAK

[tildearrow]

Attack vendors!

and can block some possible attack vendors, including stack clack attacks

(clack may not be a typo)

To be honest the name sounds to me more like a security vulnerability rather than a security improvement...

[audir8]

As someone who used grsec, it really seems like a case of grsec is dead, long live grsec. Maybe PaX will make it too, and that alone would be enough.

[Weasel]

Hold on, apps had access to the kernel stack left-over information? Wth

[DrYak]

On most common architecture (that includes the x86 family) you don't get multiple stacks, you have a unique stack per process.
When you call an OS function, it keeps executing on the same stack.
(As opposed to the 68k that has a separate "hyper visor stack pointer").

It's the kernel jobs to either write sensitive stuff to a separately allocated memory that is inaccessible to the user-land program (well, unless Meltdown completely thows any memory protection out of the window).
Or to wipe any critical stuff from the memory before returning.
Failing to do so is a security bug.
Well that was, until the latest Intel speculative fuck-up - forgot which number we're at - where it is possible that the userland code would be speculatively executing stuff depending on stack content, before the wiping has been commited to the actual RAM. (No successful exploit demonstrated on AMD hardware, though)
This kind of forced stack clearing might help against this type of speculative exploit.

Note: I am speaking about a user-land process calling a kernel function within the same process. Not an entirely different kernel process running in the background. Each process is supposed to have its own separate stack, a userland program shouldn't be able to peek into some other process unshared memory (Well, until Intel fucking up with Spectre v2. Then any userland program can force anything else (including the hypervisor) to speculatively look into normally unaccessible memory. Again, no successful exploit on anything but Intel hardware).