Hi, On Sun, Aug 01, 2021 at 09:44:33AM -0700, Kees Cook wrote: > On Sun, Aug 01, 2021 at 05:57:32PM +0200, Len Baker wrote: > > Hi, > > > > On Sun, Aug 01, 2021 at 04:00:00PM +0100, Russell King (Oracle) wrote: > > > Rather than converting every single strcpy() in the kernel to > > > strscpy(), maybe there should be some consideration given to how the > > > issue of a strcpy() that overflows the buffer should be handled. > > > E.g. in the case of a known string such as the above, if it's longer > > > than the destination, should we find a way to make the compiler issue > > > a warning at compile time? > > > > Good point. I am a kernel newbie and have no experience. So this > > question should be answered by some kernel hacker :) But I agree > > with your proposals. > > > > Kees and folks: Any comments? > > > > Note: Kees is asked the same question in [2] > > > > [2] https://lore.kernel.org/lkml/20210731135957.GB1979@titan/ > > Hi! > > Sorry for the delay at looking into this. It didn't use to be a problem > (there would always have been a compile-time warning generated for > known-too-small cases), but that appears to have regressed when, > ironically, strscpy() coverage was added. I've detailed it in the bug > report: > https://github.com/KSPP/linux/issues/88 > > So, bottom line: we need to fix the missing compile-time warnings for > strcpy() and strscpy() under CONFIG_FORTIFY_SOURCE=y. > > In the past we'd tried to add a stracpy()[1] that would only work with > const string sources. Linus got angry[2] about API explosion, though, > so we're mostly faced with doing the strscpy() replacements. > > Another idea might be to have strcpy() do the "constant strings only" > thing, leaving strscpy() for the dynamic lengths. > > One thing is clear: replacing strlcpy() with strscpy() is probably the > easiest and best first step to cleaning up the proliferation of str*() > functions. Thanks for all this info. I will work on it (clean up the proliferation of str*() functions). Regards, Len > > -Kees > > [1] https://lore.kernel.org/lkml/ed4611a4a96057bf8076856560bfbf9b5e95d390.1563889130.git.joe@xxxxxxxxxxx/ > [2] https://lore.kernel.org/lkml/CAHk-=wgqQKoAnhmhGE-2PBFt7oQs9LLAATKbYa573UO=DPBE0Q@xxxxxxxxxxxxxx/ > > -- > Kees Cook
