Messages in this thread | | | From | Marco Elver <> | Date | Wed, 9 Aug 2023 09:35:29 +0200 | Subject | Re: [PATCH v3 3/3] list_debug: Introduce CONFIG_DEBUG_LIST_MINIMAL |
| |
On Tue, 8 Aug 2023 at 23:27, Kees Cook <keescook@chromium.org> wrote: > > On Tue, Aug 08, 2023 at 12:17:27PM +0200, Marco Elver wrote: > > Numerous production kernel configs (see [1, 2]) are choosing to enable > > CONFIG_DEBUG_LIST, which is also being recommended by KSPP for hardened > > configs [3]. The feature has never been designed with performance in > > mind, yet common list manipulation is happening across hot paths all > > over the kernel. > > > > Introduce CONFIG_DEBUG_LIST_MINIMAL, which performs list pointer > > checking inline, and only upon list corruption delegates to the > > reporting slow path. > > I'd really like to get away from calling this "DEBUG", since it's used > more for hardening (CONFIG_LIST_HARDENED?). Will Deacon spent some time > making this better a while back, but the series never landed. Do you > have a bit of time to look through it? > > https://github.com/KSPP/linux/issues/10 > https://lore.kernel.org/lkml/20200324153643.15527-1-will@kernel.org/
I'm fine renaming this one. But there are other issues that Will's series solves, which I don't want this series to depend on. We can try to sort them out separately.
The main problem here is that DEBUG_LIST has been designed to be friendly for debugging (incl. checking poison values and NULL). Some kernel devs may still want that, but for production use is pointless and wasteful.
So what I can propose is to introduce CONFIG_LIST_HARDENED that doesn't depend on CONFIG_DEBUG_LIST, but instead selects it, because we still use that code to produce a report.
If there are other list types that have similar debug checks, but where we can optimize performance by eliding some and moving them inline, we can do the same (CONFIG_*_HARDENED). If the checks are already optimized, we could just rename it to CONFIG_*_HARDENED and remove the DEBUG-name.
I'm not a big fan of the 2 modes either, but that's what we get if we want to support the debugging and hardening usecases. Inlining the full set of checks does not work for performance and size.
| |