Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <e610b6fa-aa71-d612-0eb2-03ba6c4a6b46@suse.cz>
Date:   Thu, 10 Nov 2022 08:31:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
Subject: Re: Deprecating and removing SLOB
Content-Language: en-US
To:     Theodore Ts'o <tytso@mit.edu>, Aaro Koskinen <aaro.koskinen@iki.fi>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Paul Cercueil <paul@crapouillou.net>, 42.hyeyoo@gmail.com,
        akpm@linux-foundation.org, catalin.marinas@arm.com, cl@linux.com,
        iamjoonsoo.kim@lge.com, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org, penberg@kernel.org, rientjes@google.com,
        rkovhaev@gmail.com, roman.gushchin@linux.dev, willy@infradead.org,
        Feng Tang <feng.tang@intel.com>
References: <K5M3LR.3O50LSSSY5L3@crapouillou.net>
 <CAHk-=wjBqwJk9RgfoBuM00T49M7uQiLnOvLST7L6v5rhS7fkDA@mail.gmail.com>
 <20221109234832.GE307514@darkstar.musicnaut.iki.fi>
 <Y2yArTbOpKd6ASkd@mit.edu>
From:   Vlastimil Babka <vbabka@suse.cz>
In-Reply-To: <Y2yArTbOpKd6ASkd@mit.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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