On 11/10/22 05:40, Theodore Ts'o wrote:
> On Thu, Nov 10, 2022 at 01:48:32AM +0200, Aaro Koskinen wrote:
>>
>> Some of the reported SLOB issues have been actually real driver bugs,
>> that go unnoticed when SLUB/SLAB are used (unless perhaps debug stuff
>> is enabled). I'm not saying kernel should keep SLOB, but it's good at
>> failing early when there is a bug. See e.g. commit 120ee599b5bf ("staging:
>> octeon-usb: prevent memory corruption")
>
> Out of curiosity, are these bugs that would have been found using
> KASAN or some of the other kernel sanitizers and/or other debugging
> tools we have at our disposal?
Hopefully slub_debug redzoning would be able to trigger the bug described in
commit 120ee599b5bf above, which is:
> octeon-hcd will crash the kernel when SLOB is used. This usually happens
> after the 18-byte control transfer when a device descriptor is read.
> The DMA engine is always transfering full 32-bit words and if the
> transfer is shorter, some random garbage appears after the buffer.
> The problem is not visible with SLUB since it rounds up the allocations
> to word boundary, and the extra bytes will go undetected.
Ah, actually it wouldn't *now* as SLUB would make the allocation fall into
kmalloc-32 cache and only add redzone beyond 32 bytes. But with upcoming
changes by Feng Tang, this should work.
slub_debug would also have a chance of catching buffer overflows by kernel
code itself, not DMA, and tell you about it more sooner and gracefully than
crashing. KASAN also, even with a higher chance and precision, if it's
available for your arch and your device constraints can tolerate its larger
overhead.
> - Ted
>
>
