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-vji...@codeaurora.org > [2] > https://lore.kernel.org/r/cag48ez31pp--h6_fzvyfj4h86qyczafpdxtjhueean+7vje...@mail.gmail.com > [3] > https://lore.kernel.org/r/1383cd32-1ddc-4dac-b5f8-9c42282fa...@codeaurora.org > > Reported-by: Vijayanand Jitta <vji...@codeaurora.org> > Reported-by: Jann Horn <ja...@google.com> > Signed-off-by: Vlastimil Babka <vba...@suse.cz>
Reviewed-by: Kees Cook <keesc...@chromium.org> -- Kees Cook
