Re: Deprecating and removing SLOB

[Vlastimil Babka]

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
> 
>