| 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
| ||
|
Message-ID: <aUEwre1bkwrj-i4i@pathway.suse.cz>
Date: Tue, 16 Dec 2025 11:13:01 +0100
From: Petr Mladek <pmladek@...e.com>
To: Tamir Duberstein <tamird@...nel.org>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Steven Rostedt <rostedt@...dmis.org>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Kees Cook <kees@...nel.org>, linux-kernel@...r.kernel.org,
oe-kbuild-all@...ts.linux.dev, kernel test robot <lkp@...el.com>
Subject: Re: [PATCH] printf: add __printf attribute
On Mon 2025-12-08 16:07:28, Tamir Duberstein wrote:
> On Mon, Dec 8, 2025 at 9:06 AM Petr Mladek <pmladek@...e.com> wrote:
> >
> > On Mon 2025-12-08 15:30:53, Andy Shevchenko wrote:
> > > On Sun, Dec 07, 2025 at 08:32:53PM -0500, Tamir Duberstein wrote:
> > > > On Sat, Dec 6, 2025 at 4:45 PM Andy Shevchenko
> > > > <andriy.shevchenko@...ux.intel.com> wrote:
> > > > > On Sat, Dec 06, 2025 at 02:57:48PM -0500, Tamir Duberstein wrote:
> > > > > > On Sat, Dec 6, 2025 at 2:43 PM Andy Shevchenko
> > > > > > <andriy.shevchenko@...ux.intel.com> wrote:
> > > > > > > On Sat, Dec 06, 2025 at 12:52:53PM -0500, Tamir Duberstein wrote:
> > > > > > > > On Sat, Dec 6, 2025 at 12:49 PM Andy Shevchenko
> > > > > > > > <andriy.shevchenko@...ux.intel.com> wrote:
> > > > > > > > > On Sat, Dec 06, 2025 at 12:13:34PM -0500, Tamir Duberstein wrote:
> > > > > > > > > > On Sat, Dec 6, 2025 at 11:11 AM Andy Shevchenko
> > > > > > > > > > <andriy.shevchenko@...ux.intel.com> wrote:
> > > > > > > > > > > On Sat, Dec 06, 2025 at 08:19:09AM -0500, Tamir Duberstein wrote:
> > >
> > > ...
> > >
> > > > > > > > > > > > -static void
> > > > > > > > > > > > +static void __printf(2, 3)
> > > > > > > > > > >
> > > > > > > > > > > 3?!
> > > > > > > > > > >
> > > > > > > > > > > I think it should be (2, 0). Yes, the both users call it with "%p..." in format
> > > > > > > > > > > string, but the second parameter tells compiler to check the variadic
> > > > > > > > > > > arguments, which are absent here. Changing 'const void *p' to '...' will align
> > > > > > > > > > > it with the given __printf() attribute, but I don't know if this what we want.
> > > > > > > > > >
> > > > > > > > > > The second parameter is the first-to-check, it is not specific to
> > > > > > > > > > variadic arguments. Using 0 means that no arguments are checkable, so
> > > > > > > > > > the compiler only validates the format string itself and won’t
> > > > > > > > > > diagnose mismatches with `p`. This works whether or not we later
> > > > > > > > > > change `const void *p` to `...`.
> > > > > > > > >
> > > > > > > > > Yes, but this is fragile. As I explained it works only because we supply
> > > > > > > > > the format string stuck to "%p", anything else will require reconsidering
> > > > > > > > > the function prototypes. So, strictly speaking this should be (2, 0) if
> > > > > > > > > we leave const void *p as is.
> > > > > > > > >
> > > > > > > > I believe this is not correct. As I said, 0 means "do not check
> > > > > > > > arguments" so only the format string will be checked. See the existing
> > > > > > > > uses of this annotation in this file:
> > > > > > > >
> > > > > > > > static void __printf(7, 0)
> > > > > > > > do_test(struct kunit *kunittest, const char *file, const int line, int
> > > > > > > > bufsize, const char *expect,
> > > > > > > > int elen, const char *fmt, va_list ap)
> > > > > > > >
> > > > > > > > and
> > > > > > > >
> > > > > > > > static void __printf(6, 7)
> > > > > > > > __test(struct kunit *kunittest, const char *file, const int line,
> > > > > > > > const char *expect, int elen,
> > > > > > > > const char *fmt, ...)
> > > > >
> > > > Since it doesn't make much sense to make this function variadic, I
> > > > think the best we can do is a macro wrapper that combines this
> > > > function with `no_printk`. Something like
> > > >
> > > > #define test_hashed(kunittest, fmt, p) \
> > > > do { \
> > > > if (0) \
> > > > no_printk(fmt, p); \
> > > > __test_hashed(kunittest, fmt, p);\
> > > > } while (0)
> > >
> >
> > IMHO, this is is not worth it. test_hashed(kunittest, fmt, p) calls
> > test(buf, fmt, p). It goes down to __test() which does the format
> > check:
> >
> > static void __printf(6, 7)
> > __test(struct kunit *kunittest, const char *file, const int line, const char *expect, int elen,
> > const char *fmt, ...)
> >
> >
> > > > That would give us better diagnostics, but is more complex (and more
> > > > lines of code than just repeating this function's body twice, which
> > > > would also give good diagnostics). I think the best thing to do is just
> > > > to ignore the report that prompted me to look into this. Please let me
> > > > know if you disagree.
> > >
> > > I think we may not ignore the report as it breaks builds in some cases.
> > > As I said
> > >
> > > - __printf(2, 0) for now
> > >
> > > - and perhaps a comment on top to explain the clang approach that may cope
> > > with fixed-argument functions for -Wformat (you can even put a link to that
> > > LLVM discussion about the feature).
> >
> > I personally prefer this way. We just need to calm down the warning.
> > The proper check is done by the nested test()...
>
> The nested `__test()` call cannot do the proper check because it cannot
> see the format string. Right?
IMHO, it does see the format string. It is defined the following way:
static void __printf(6, 7)
__test(struct kunit *kunittest, const char *file, const int line, const char *expect, int elen,
const char *fmt, ...)
#define test(expect, fmt, ...) \
__test(kunittest, __FILE__, __LINE__, expect, strlen(expect), fmt, ##__VA_ARGS__)
static void
test_hashed(struct kunit *kunittest, const char *fmt, const void *p)
{
char buf[PLAIN_BUF_SIZE];
plain_hash_to_buffer(kunittest, p, buf, PLAIN_BUF_SIZE);
test(buf, fmt, p);
}
Now, let's get for example:
test_hashed(kunittest, "%p", PTR_INVALID);
it calls:
test(buf, "%p", PTR_INVALID);
which is exapnded to:
__test(kunittest, file, line, buf, strlen(buf), "%p", PTR_INVALID)
so, it gets the same printf arguments as the original test_hashed,
namely:
%p, PTR_INVALID
Or do I miss anything, please?
You might argue that it works by chance and that it might change in the
future. But I have hard times to imagine it. test_hashed() is just
a wrapper around "test()". The only purpose is to fill "buf" with
the expected outcome.
If any refactoring is needed in the future. The __printf() macros
would need some refactoring as well.
Best Regards,
Petr
Powered by blists - more mailing lists