[Linux-kernel-mentees] deprecated.rst: deprecated strcpy ? (was: [PATCH] checkpatch: add a new check for strcpy/strlcpy uses)
David.Laight at ACULAB.COM
Fri Jan 8 10:05:52 UTC 2021
From: Joe Perches
> Sent: 08 January 2021 00:52
> > The original goal was to use another helper that worked on static
> > strings like this. Linus rejected that idea, so we're in a weird place.
> > I think we could perhaps build a strcpy() replacement that requires
> > compile-time validated arguments, and to break the build if not.
> > i.e.
> > given:
> > char array;
> > char *ptr;
> > allow:
> > strcpy(array, "1234567");
> > disallow:
> > strcpy(array, "12345678"); /* too long */
> > strcpy(array, src); /* not optimized, so use strscpy? */
> > strcpy(ptr, "1234567"); /* unknown destination size */
> > strcpy(ptr, src); /* unknown destination size */
> I think that's not a good idea as it's not a generic equivalent of the
> string.h code.
> I still like the stracpy variant I proposed:
> Linus liked a variant he called copy_string:
> I think the cocci scripts that convert:
> strlcpy -> strscpy (only when return value unused)
> str<sln>cpy(array, "string") -> stracpy(foo, "string")
> s[cn]printf -> sysfs_emit
> would leave relatively few uses of strcpy and sprintf variants and would
> make it much easier to analyze the remainder uses for potential overflows.
The advantage of allowing strcpy() but only when the when it can be
converted into a non-overflowing memcpy() is that you know that the
copies never get truncated.
The next round of string copy errors could easily by the 'silent truncation'
ones - so using such a strcpy() will cut down the next audit.
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
More information about the Linux-kernel-mentees