Finer Grained KASLR Patches Revived For The Linux Kernel To Enhance Security

[phoronix]

Phoronix: Finer Grained KASLR Patches Revived For The Linux Kernel To Enhance Security

For more than a year there has been work on FGKASLR for finer grained kernel address space layout randomization. While KASLR is widely-used these days, with enough guessing or unintentional kernel leakage, the base address of the kernel can be figured out. Finer grained KASLR allows for randomization at the per-functional level to dramatically boost defenses. The latest take on FG-KASLR has now been published...

https://www.phoronix.com/scan.php?page=news_item&px=FGKASLR-v6-Linux

[debrouxl]

Meanwhile, some exploits are written in such a way that they're compatible with, or defeat, FG-KASLR ( https://mobile.twitter.com/grsecurit...56009616543745 -> https://www.willsroot.io/2021/08/cor...n-writeup.html ) in addition to KASLR and all other mainline "defenses", and spender clearly has complete defeats of FG-KASLR ( https://mobile.twitter.com/spendergr...48705506488320 ) - he doesn't have a history of fibbing.

Yet another half-baked, easily defeatable "security" technology in mainline Linux which will further increase complexity and costs (the cover letter mentions a minute linking the kernel and worse, a second on kernel boot up time, linear with the number of such boots !) while not improving Linux's actual security posture much in practice ?

[ssokolow]

Yet another half-baked, easily defeatable "security" technology in mainline Linux which will further increase complexity and costs (the cover letter mentions a minute linking the kernel and worse, a second on kernel boot up time, linear with the number of such boots !) while not improving Linux's actual security posture much in practice ?

Don't grsecurity have a financial incentive to say "the Linux kernel's security is worthless, but signing a contract to use our patch set makes it more secure than anything else in the world"?

[RahulSundaram]

Don't grsecurity have a financial incentive to say "the Linux kernel's security is worthless, but signing a contract to use our patch set makes it more secure than anything else in the world"?

Yes they do. When their patches used to be public, they could atleast point to a better method of doing things but this is no longer the case. Read the following for more background:

https://lwn.net/Articles/721848/

https://perens.com/2017/06/28/warnin...for-customers/

It used to be the case that Linux developers were very resistant towards security hardening efforts but this is no longer the case (although they are still not transparency when committing security fixes) and a large number of hardening features have been merged upstream by now.

[debrouxl]

Indeed, they do, especially since 2017, but they have a point: their stuff is immensely more secure than anything else
And now that they can actually make a living out of it (remember, they previously provided the code at no cost for ~16 years and could only work on it in their free time because very few people donated money...), the gap between mainline and the commercial stuff keeps widening: improved RAP, RESPECTRE instead of ad-hoc manual patching of a small subset of Spectre gadgets in mainline, AUTOSLAB, etc.

On the contrary, it's a fact that the main Linux developers remain resistant towards the useful security efforts:
* no MEMORY_UDEREF or KERNEXEC, good for foiling exploits on older hardware which remains widely used in the real world;
* lashing out at and talking about removing GCC plugins instead of strongly embracing them for full-featured CONSTIFY + RANDSTRUCT + integer overflow protection + RESPECTRE + RAP + infoleak reduction + etc.;
* making security stuff opt-in rather than opt-out, e.g. the refcount changes in mainline.

However, mainline tends to integrate complex stuff of limited to low protective ability, KASLR and FG-KASLR being prime examples of such security hardening efforts, in the absence of a concerted mainline effort to clamp down on infoleaks, which negate the effect of this randomization...

Once in every while, spender and/or I used to play the game of pointing out, in LWN comments for news items about exploits for Linux vulnerabilities, which PaX/grsecurity features prevented the given exploits from working. Sometimes, it was all of what I dubbed the "magic 4" based on the output of these comments: the exploit rewrote an ops struct (which would have been made const by CONSTIFY) to change one of the pointers it contains (at an offset which would have been randomized by RANDSTRUCT - mainline eventually integrated an older, weaker form of that), then blissfully proceeded to both dereferencing user-space directly (MEMORY_UDEREF forbids that) and executing user-space memory directly (KERNEXEC forbids that).
Remember, PaX/grsec features foiled the published exploit without requiring special hardware features found only in newer hardware (SMEP / SMAP, PXN / PAN), though PaX/grsec has been using the available hardware features to strengthen the effect and/or reduce the speed impact since before mainline did (e.g. leveraging PCID / INVPCID for faster MEMORY_UDEREF and/or KERNEXEC a while before mainline did to lower the performance impact of KPTI).
Add a sprinkling of ROP/JOP in the exploit and get it foiled by the fifth major PaX feature, RAP, which again, has no equivalent in mainline. No, Clang CFI isn't it in terms of either protective power or speed impact, you can look for yourselves at spender/PaXTeam's detailed explanations on that topic - and anyway, none of the major Linux desktop/server distros uses Clang to build the kernel, so Clang CFI for the Linux kernel is completely irrelevant in the real world for desktop/server usage at the time of this writing. EDIT: GCC doesn't support CFI, beyond the weak Intel CET (PaXTeam's detailed analysis is clear about that) that very few x86_64 processors support. It will take years before these processors represent a majority in the real world of desktop and server computers...

EDIT: RAP was originally designed to store CFI data close (enough) to the instrumented code, and the latest official public version wasn't compatible with the execute-only memory that the likes of Kees Cook want to see integrated into mainline (and they use this fact as an argument against RAP). But I'd take RAP with forwards edge + backwards edge + randomized CFI without execute-only memory support - a limitation which might have been overcome by now - over slower and less protective CFI which happens to be compatible with execute-only memory. Any day.