AUTOSLAB ?

Posted Aug 22, 2024 23:49 UTC (Thu) by kees (subscriber, #27264)
In reply to: AUTOSLAB ? by Lionel_Debroux
Parent article: Per-call-site slab caches for heap-spraying protection

Once the new kmalloc_obj() API is finalized I'll make time to get some benchmarking done on this series for the next version. If you or anyone else would like to participate in this effort, I would welcome such an analysis!

As far as inspiration, this series is not trying to implement what AUTOSLAB claims to do. The implementation goals come from all over the place, including MTE, kCTF patches, PartitionAlloc, the XNU kmalloc_type allocator, the GrapheneOS hardened_malloc, etc. Heap defense research is hardly unique to grsecurity. :)

As for the Perens article quote being "factually incorrect", is grsecurity no longer a commercial product? Regardless, random monolithic source leaks is hardly useful for making robust upstream improvements. Besides, Linux has moved away from compiler plugins -- we've been driving language extensions directly in Clang and GCC so the entire Open Source ecosystem can benefit, and then refactoring Linux itself to gain better language robustness and hardening coverage.

AUTOSLAB ?

Posted Aug 23, 2024 8:11 UTC (Fri) by Lionel_Debroux (subscriber, #30014) [Link]

From years of browsing through the PaX & grsecurity patches before 2017, less so afterwards, I was usually able to quickly understand which protection the given hunks dealt with. While some of the protections, for instance KERNEXEC and MEMORY_UDEREF (both among the 5-6 defenses which foiled the implementations of most Linux exploits mentioned on LWN back in the day, without requiring SMEP/SMAP/PXN/PAN/equivalent hardware capabilities which were still scarce in 2017) are largely all-or-nothing, many bits related to e.g. constification and staticification of ops structs, structure layout randomization, or CFI, can be used to make robust upstream improvements. If people - preferably persons actually paid for that task, instead of relying on unpaid volunteers working in their spare time - do it, that is...

You're mentioning moving away from infrastructure (compiler plugins) which has made it possible to provide ongoing support for a wide range of compiler versions for a decade or so, in order to replace it by built-in implementations of a subset of the capabilities provided by compiler plugins into only the newest and future compiler versions, while producing crippled kernel builds on compiler versions which don't support these newfangled extensions - i.e. most of them.
It's an interesting approach, which certainly has upsides beyond Linux (just like the GCC Rust efforts, which Open Source Security Inc. has been one of the very few entities providing actual funding to), if people start to use these language extensions. Their approach is arguably more practical, though. And they can still pull it as a tiny company, which has nowhere remotely near the resources any of the large Linux companies has access to.