linux-kernel - Re: Deprecating and removing SLOB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e610b6fa-aa71-d612-0eb2-03ba6c4a6b46@suse.cz>
Date:   Thu, 10 Nov 2022 08:31:31 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Theodore Ts'o <tytso@....edu>, Aaro Koskinen <aaro.koskinen@....fi>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Paul Cercueil <paul@...pouillou.net>, 42.hyeyoo@...il.com,
        akpm@...ux-foundation.org, catalin.marinas@....com, cl@...ux.com,
        iamjoonsoo.kim@....com, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, penberg@...nel.org, rientjes@...gle.com,
        rkovhaev@...il.com, roman.gushchin@...ux.dev, willy@...radead.org,
        Feng Tang <feng.tang@...el.com>
Subject: Re: Deprecating and removing SLOB

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