Re: Deprecating and removing SLOB

[Feng Tang]

On Thu, Nov 10, 2022 at 03:31:31PM +0800, Vlastimil Babka wrote:
> 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.
 
I wrote a simple case trying simulating this:

	static noinline void dma_align_test(void)
	{
		char *buf;

		buf = kmalloc(18, GFP_KERNEL);
		buf[18] = 0;
		buf[19] = 0;
		kfree(buf);
	}

And with slub_debug on and the slub_redzone patchset[1], it did
catch the out-of-bound access, as in the dmesg:

"
 =============================================================================
 BUG kmalloc-32 (Not tainted): kmalloc Redzone overwritten
 -----------------------------------------------------------------------------

 0xffff888005ebb032-0xffff888005ebb033 @offset=50. First byte 0x0 instead of 0xcc
 Allocated in dma_align_test+0x1b/0x29 age=6554 cpu=1 pid=1
  __kmem_cache_alloc_node+0x2a7/0x320
  kmalloc_trace+0x27/0xa0
  dma_align_test+0x1b/0x29
  late_slub_debug+0xa/0x11
  do_one_initcall+0x87/0x2a0
  ...

 Slab 0xffffea000017aec0 objects=21 used=19 fp=0xffff888005ebbf20 flags=0xfffffc0000200(slab|node=0|zone=1|lastcpupid=0x1fffff)
 Object 0xffff888005ebb020 @offset=32 fp=0x0000000000000000

 Redzone  ffff888005ebb000: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
 Redzone  ffff888005ebb010: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
 Object   ffff888005ebb020: 50 92 28 00 81 88 ff ff 01 00 00 00 11 00 b6 07  P.(.............
 Object   ffff888005ebb030: 6b a5 00 00 cc cc cc cc cc cc cc cc cc cc cc cc  k...............
 Redzone  ffff888005ebb040: cc cc cc cc cc cc cc cc                          ........
 Padding  ffff888005ebb0a4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
 Padding  ffff888005ebb0b4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a              ZZZZZZZZZZZZ
"

[1]. https://lore.kernel.org/lkml/20221021032405.1825078-1-feng.tang@xxxxxxxxx/ 

Thanks,
Feng

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