Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] API replacement/deprecation

[Arnd Bergmann <arnd@arndb.de>]

On Fri, Sep 7, 2018 at 6:12 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Sep 7, 2018 at 7:33 AM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
> > On Thu, Sep 06, 2018 at 04:24:03PM -0700, Kees Cook wrote:
> >>
> >> Hopefully we can all agree on deprecating strcpy() and strncpy() in
> >> favor of strscpy()?
> >
> > There are some places where I use strncpy for a character array which
> > is *not* a null-terminated string.  What is the preferred alternative
> > for me?  I can suppress the problem when gcc complains about it using:
> >
> > +       __u8    s_first_error_func[32] __nonstring;     /* function where the error happened */
> >
> > But if we do a blanket deprecation, what should I use instead?
>
> strncpy() is a weird one. I think we can easily say "no strcpy()" but
> for strncpy() we need to examine the existing use-cases:
>
> - non-NUL-terminated: use memcpy?
> - NEEDS trailing NUL padding: ... no solution yet. invent strscpy_pad() ?
> - "safe" strcpy(): use strscpy()

I suspect that a lot of the cases that want NUL-padding also don't
want NUL-termination: when you store a string on disk in a fixed-length
record or transfer it over the network, you don't want to leak stack
data to the medium, but you also don't need the terminating character
because you know the maximum length already.

strncpy() does exactly the right thing for that case, it's just that
this pattern is now a corner case, and gcc tends to flag such
usage with a warning about missing termination (unless you
use __nonstring) but doesn't flag the more common usage when
it looks correct.

       Arnd