linux-kernel - Re: [RFC v5 6/7] sprintf: Add [v]sprintf

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: <20250711184541.68d770b9@pumpkin>
Date: Fri, 11 Jul 2025 18:45:41 +0100
From: David Laight <david.laight.linux@...il.com>
To: Martin Uecker <ma.uecker@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Alejandro Colomar 
 <alx@...nel.org>, linux-mm@...ck.org, linux-hardening@...r.kernel.org, Kees
 Cook <kees@...nel.org>, Christopher Bazley <chris.bazley.wg14@...il.com>,
 shadow <~hallyn/shadow@...ts.sr.ht>, linux-kernel@...r.kernel.org, Andrew
 Morton <akpm@...ux-foundation.org>, kasan-dev@...glegroups.com, Dmitry
 Vyukov <dvyukov@...gle.com>, Alexander Potapenko <glider@...gle.com>, Marco
 Elver <elver@...gle.com>, Christoph Lameter <cl@...ux.com>, David Rientjes
 <rientjes@...gle.com>, Vlastimil Babka <vbabka@...e.cz>, Roman Gushchin
 <roman.gushchin@...ux.dev>, Harry Yoo <harry.yoo@...cle.com>, Andrew
 Clayton <andrew@...ital-domain.net>, Rasmus Villemoes
 <linux@...musvillemoes.dk>, Michal Hocko <mhocko@...e.com>, Al Viro
 <viro@...iv.linux.org.uk>, Sam James <sam@...too.org>, Andrew Pinski
 <pinskia@...il.com>
Subject: Re: [RFC v5 6/7] sprintf: Add [v]sprintf_array()

On Fri, 11 Jul 2025 08:05:38 +0200
Martin Uecker <ma.uecker@...il.com> wrote:

> Am Donnerstag, dem 10.07.2025 um 14:58 -0700 schrieb Linus Torvalds:
> > On Thu, 10 Jul 2025 at 14:31, Alejandro Colomar <alx@...nel.org> wrote:  
> > > 
> > > These macros are essentially the same as the 2-argument version of
> > > strscpy(), but with a formatted string, and returning a pointer to the
> > > terminating '\0' (or NULL, on error).  
> > 
> > No.
> > 
> > Stop this garbage.
> > 
> > You took my suggestion, and then you messed it up.
> > 
> > Your version of sprintf_array() is broken. It evaluates 'a' twice.
> > Because unlike ARRAY_SIZE(), your broken ENDOF() macro evaluates the
> > argument.
> > 
> > And you did it for no reason I can see. You said that you wanted to
> > return the end of the resulting string, but the fact is, not a single
> > user seems to care, and honestly, I think it would be wrong to care.
> > The size of the result is likely the more useful thing, or you could
> > even make these 'void' or something.
> > 
> > But instead you made the macro be dangerous to use.
> > 
> > This kind of churn is WRONG. It _looks_ like a cleanup that doesn't
> > change anything, but then it has subtle bugs that will come and bite
> > us later because you did things wrong.
> > 
> > I'm NAK'ing all of this. This is BAD. Cleanup patches had better be
> > fundamentally correct, not introduce broken "helpers" that will make
> > for really subtle bugs.
> > 
> > Maybe nobody ever ends up having that first argument with a side
> > effect. MAYBE. It's still very very wrong.
> > 
> >                 Linus  
> 
> What I am puzzled about is that - if you revise your string APIs -,
> you do not directly go for a safe abstraction that combines length
> and pointer and instead keep using these fragile 80s-style string
> functions and open-coded pointer and size computations that everybody
> gets wrong all the time.
> 
> String handling could also look like this:

What does that actually look like behind all the #defines and generics?
It it continually doing malloc/free it is pretty much inappropriate
for a lot of system/kernel code.

	David

> 
> 
> https://godbolt.org/z/dqGz9b4sM
> 
> and be completely bounds safe.
> 
> (Note that those function abort() on allocation failure, but this
> is an unfinished demo and also not for kernel use. Also I need to
> rewrite this using string views.)
> 
> 
> Martin
> 
> 
> 
>