On Tue, Jun 02, 2020 at 04:15:16PM +0200, Vlastimil Babka wrote: > SLUB_DEBUG creates several files under /sys/kernel/slab/<cache>/ that can be > read to check if the respective debugging options are enabled for given cache. > The options can be also toggled at runtime by writing into the files. Some of > those, namely red_zone, poison, and store_user can be toggled only when no > objects yet exist in the cache. > > Vijayanand reports [1] that there is a problem with freelist randomization if > changing the debugging option's state results in different number of objects > per page, and the random sequence cache needs thus needs to be recomputed. > > However, another problem is that the check for "no objects yet exist in the > cache" is racy, as noted by Jann [2] and fixing that would add overhead or > otherwise complicate the allocation/freeing paths. Thus it would be much > simpler just to remove the runtime toggling support. The documentation > describes it's "In case you forgot to enable debugging on the kernel command > line", but the neccessity of having no objects limits its usefulness anyway for > many caches. > > Vijayanand describes an use case [3] where debugging is enabled for all but > zram caches for memory overhead reasons, and using the runtime toggles was the > only way to achieve such configuration. After the previous patch it's now > possible to do that directly from the kernel boot option, so we can remove the > dangerous runtime toggles by making the /sys attribute files read-only. > > While updating it, also improve the documentation of the debugging /sys files. > > [1] https://lkml.kernel.org/r/1580379523-32272-1-git-send-email-vjitta@xxxxxxxxxxxxxx > [2] https://lore.kernel.org/r/CAG48ez31PP--h6_FzVyfJ4H86QYczAFPdxtJHUEEan+7VJETAQ@xxxxxxxxxxxxxx > [3] https://lore.kernel.org/r/1383cd32-1ddc-4dac-b5f8-9c42282fa81c@xxxxxxxxxxxxxx > > Reported-by: Vijayanand Jitta <vjitta@xxxxxxxxxxxxxx> > Reported-by: Jann Horn <jannh@xxxxxxxxxx> > Signed-off-by: Vlastimil Babka <vbabka@xxxxxxx> Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> -- Kees Cook
