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: <d43ebab47ee70cd11bddf78c424ec341b4c797cf.camel@gmail.com>
Date: Tue, 15 Jul 2025 08:24:29 +0200
From: Martin Uecker <ma.uecker@...il.com>
To: Kees Cook <kees@...nel.org>, Linus Torvalds
 <torvalds@...ux-foundation.org>
Cc: David Laight <david.laight.linux@...il.com>, Alejandro Colomar
 <alx@...nel.org>, linux-mm@...ck.org, linux-hardening@...r.kernel.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 Montag, dem 14.07.2025 um 22:19 -0700 schrieb Kees Cook:
> On Fri, Jul 11, 2025 at 10:58:56AM -0700, Linus Torvalds wrote:
> >         struct seq_buf s;
> >         seq_buf_init(&s, buf, szie);
> 
> And because some folks didn't like this "declaration that requires a
> function call", we even added:
> 
> 	DECLARE_SEQ_BUF(s, 32);
> 
> to do it in 1 line. :P
> 
> I would love to see more string handling replaced with seq_buf.

Why not have?

struct seq_buf s = SEQ_BUF(32);


So the kernel has safe abstractions, there are just not used enough.

Do you also have a string view abstraction?  I found this really
useful as basic building block for safe string handling, and
equally important to a string builder type such as seq_buf.

The string builder is for safely construcing new strings, the
string view is for safely accessing parts of existing strings.


Also what I found really convenient and useful in this context
was to have an accessor macro that expose the  buffer as a 
regular array cast to the correct size:

 *( (char(*)[(x)->N]) (x)->data )

(put into statement expressions to avoid double evaluation)

instead of simply returning a char*


You can then access the array directly with [] which then can be
bounds checked with UBsan, one can measure its length with sizeof,
and one can also let it decay and get a char* to pass it to legacy
code (and to some degree this can be protected by BDOS).


Martin