linux-kernel - Re: [PATCH v2 2/3] lib/vsprintf: Split out sprintf() and friends

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]

Date:   Mon, 7 Aug 2023 21:31:38 +0200
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Petr Mladek <pmladek@...e.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Marco Elver <elver@...gle.com>, linux-kernel@...r.kernel.org,
        kasan-dev@...glegroups.com, linux-mm@...ck.org,
        Steven Rostedt <rostedt@...dmis.org>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Alexander Potapenko <glider@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2 2/3] lib/vsprintf: Split out sprintf() and friends

On 07/08/2023 17.03, Petr Mladek wrote:

> I agree that kernel.h is not the right place. But are there any
> numbers how much separate sprintf.h might safe?
> 
> Maybe, we should not reinvent the wheel and get inspired by
> userspace.
> 
> sprintf() and friends are basic functions which most people know
> from userspace. And it is pretty handy that the kernel variants
> are are mostly compatible as well.
> 
> IMHO, it might be handful when they are also included similar way
> as in userspace. From my POV printk.h is like stdio.h. And we already
> have include/linux/stdarg.h where the v*print*() function might
> fit nicely.
> 
> How does this sound, please?

No, please. Let's have a separate header for the functions defined in
vsprintf.c. We really need to trim our headers down to something more
manageable, and stop including everything from everywhere just because
$this little macro needs $that little inline function.

I did https://wildmoose.dk/header-bloat/ many moons ago, I'm sure it
looks even worse today. I also did some sparse-hackery to let it tell me
which macros/functions/types were declared/defined in a given .h file,
and then if some .c file included that .h file but didn't use any of
those, the #include could go away.

Sure, individually, moving the sprintf family out of kernel.h won't save
much (and, of course, nothing at all initially when we're forced to add
an include of that new header from kernel.h). But this technical debt
has crept in over many years, it's not going away in one or two
releases. And use of the sprintf family is very easy to grep for, so
it's a good low-hanging fruit where we should be able to make everybody
who needs one of them include the proper header, and then drop the
include from kernel.h.

Rasmus