linux-hardening - 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: <7deb2ddcf0f3e6cd196b7520ad19e0d2ce07c639.camel@gmail.com>
Date: Fri, 11 Jul 2025 20:01:01 +0200
From: Martin Uecker <ma.uecker@...il.com>
To: David Laight <david.laight.linux@...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()

Am Freitag, dem 11.07.2025 um 18:45 +0100 schrieb David Laight:
> 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.

The example I linked would allocate behind your back and would clearly
not be useful for the kernel also because it would abort() on
allocation failure (as I pointed out below).  

Still, I do not see why similar functions could not work for the
kernel.  The main point is to keep pointer and length together in a
single struct.  But it is certainly more difficult to define APIs
which make sense for the kernel.

I explain a bit how such types work here:

https://uecker.codeberg.page/2025-07-02.html
https://uecker.codeberg.page/2025-07-09.html

Martin
> 

> > 
> > 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
> > 
> > 
> > 
> > 
>