linux-hardening - RE: [PATCH v3 3/4] string: Allow 2-argument strscpy

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] [day] [month] [year] [list]

Date: Sat, 10 Feb 2024 12:34:41 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Kees Cook' <keescook@...omium.org>, Justin Stitt <justinstitt@...gle.com>
CC: Andy Shevchenko <andy@...nel.org>, "linux-hardening@...r.kernel.org"
	<linux-hardening@...r.kernel.org>, Richard Weinberger <richard@....at>,
	"Anton Ivanov" <anton.ivanov@...bridgegreys.com>, Johannes Berg
	<johannes@...solutions.net>, Willem de Bruijn
	<willemdebruijn.kernel@...il.com>, Jason Wang <jasowang@...hat.com>, "kernel
 test robot" <lkp@...el.com>, Nathan Chancellor <nathan@...nel.org>, "Azeem
 Shaikh" <azeemshaikh38@...il.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-um@...ts.infradead.org"
	<linux-um@...ts.infradead.org>
Subject: RE: [PATCH v3 3/4] string: Allow 2-argument strscpy_pad()

From: Kees Cook
> Sent: 07 February 2024 09:19
> 
> On Wed, Feb 07, 2024 at 12:51:51AM +0000, Justin Stitt wrote:
> > Hi,
> >
> > On Tue, Feb 06, 2024 at 06:22:18AM -0800, Kees Cook wrote:
> > > Similar to strscpy(), update strscpy_pad()'s 3rd argument to be
> > > optional when the destination is a compile-time known size array.
> >
> > This patch is diff'd against Patch 1/4 in this series, right? I wonder
> > why you split them up. If I hadn't literally just read that patch I
> > would be mildly confused.
> >
> > I suppose one reason may be that 1/4 is a standalone change with a high
> > percentage chance of landing whilst this overloading magic may not land
> > as easily?
> 
> I viewed it as a distinct logical change. I could certainly combine
> them, but I think it's easier to review the conversion from function to
> macro without needing to consider anything else. No behavioral changes
> are expected, etc.

I wonder about the code-bloat from inlining strscpy_pad()?
Especially given the code that gcc is likely to generate
for string ops.

I strongly suspect that the end of strscpy() knows exactly
you many bytes weren't written (in the non-truncate path).
So maybe implement both strscpy() and strscp_pad() in terms
of an inline function that has a parameter that 'turns on'
padding.

That way you get a simple call site and still only one
implementation.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)