Linux's SLUB Allocator Preparing To Better Fend Off Cross-Cache Attacks

[phoronix]

Phoronix: Linux's SLUB Allocator Preparing To Better Fend Off Cross-Cache Attacks

Following SLOB's removal and SLAB being deprecated and set for removal, the Linux kernel is all-in on the SLUB allocator. A new patch series posted on Friday is aiming to help prevent the possibility of cross-cache attacks with the SLUB memory allocator in the kernel...

https://www.phoronix.com/news/Linux-SLUB-Prevent-Cross-Cache

[coder]

I'm not sure I totally follow the scenario this is meant to address, but I'm wondering why pages aren't simply zero'd, when moved between different types of pools. Perhaps that would be preferable, in some ways, to restricting their movement.

On a related note, I've read that Apple's recent CPUs contain special optimizations for moving large blocks of zeros over their internal buses and caches.

[ddriver]

Ummm isn't it pretty much common practice to explicitly wipe sensitive buffers before deallocation?

[Markopolo]

Ummm isn't it pretty much common practice to explicitly wipe sensitive buffers before deallocation?

This isn’t so much about leaking data as defence in depth. The patch series assumes there is a use-after-free bug somewhere in the kernel. This patch limits the types of data that can be re-used such that they are the same type or at least same size object. That way the type confusion is more limited and hopefully makes it harder for the attacker to get full control.

[elbar]

Warning: C/C++ incorporated, user space assembler needed

[Developer12]

This sounds like it'd create a lot of fragmentation, just to half-mitigate exploitation of a C footgun. It doesn't even try to mitigate the use-after-free, merely restrict it to objects of the same approximate size.