linux-kernel - Re: [PATCH v4 05/34] vsprintf: %pf(%p)

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]

Message-ID: <bdedc4fd-e627-a23e-f00a-615dc087c670@rasmusvillemoes.dk>
Date:   Tue, 21 Jun 2022 10:47:23 +0200
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Kent Overstreet <kent.overstreet@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org, pmladek@...e.com,
        rostedt@...dmis.org, enozhatsky@...omium.org, willy@...radead.org
Subject: Re: [PATCH v4 05/34] vsprintf: %pf(%p)

On 21/06/2022 09.51, Kent Overstreet wrote:

>>>  struct printf_spec {
>>> @@ -2520,7 +2521,16 @@ int format_decode(const char *fmt, struct printf_spec *spec)
>>>  		return ++fmt - start;
>>>  
>>>  	case 'p':
>>> -		spec->type = FORMAT_TYPE_PTR;
>>> +		fmt++;
>>> +		if (fmt[0] == 'f' &&
>>> +		    fmt[1] == '(') {
>>> +			fmt += 2;
>>> +			spec->type = FORMAT_TYPE_FN;
>>> +		} else
>>> +			spec->type = FORMAT_TYPE_PTR;
>>> +		return fmt - start;
>>> +	case '(':
>>> +		spec->type = FORMAT_TYPE_FN;
>>>  		return ++fmt - start;
>>
>> NAK. Don't implement something that will never be tested nor used.
>> There's not a snowball's chance in hell that we'll ever build the kernel
>> without -Wformat.
> 
> We're not stopping here. Matthew is taking this to WG14 and I'll be working on
> adding this functionality to glibc next, and %() is the syntax we intend to take
> to the working group.
> 
> But the working group is naturally going to want to see that a working
> implementation of it exists.

OK. But implementation in glibc, musl and/or the kernel is much much
less interesting than support in gcc and clang for accepting %( in the
first place, and preferably also for not just treating %( as a synonym
for %p but actually checking that the argument is a function pointer and
 that its signature matches the arguments between (). Once _that_ has
landed in gcc 24 and the kernel requirements have been bumped to that
can we consider adding "%(" format strings (and the necessary support).

Yes, I appreciate the chicken-and-egg situation. No, I don't think the
mainline kernel is a suitable place for proof-of-concept and highly
experimental code.

Rasmus