All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Paolo Abeni <pabeni@redhat.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-hardening@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] string: Introduce strtomem() and strtomem_pad()
Date: Thu, 1 Sep 2022 11:35:17 -0700	[thread overview]
Message-ID: <202209011123.27D7D67@keescook> (raw)
In-Reply-To: <CAMuHMdX1H_ssPDJH47kcXhmoAZzYEgJC2zaMp-d_2+VriZYAoA@mail.gmail.com>

On Thu, Sep 01, 2022 at 10:39:19AM +0200, Geert Uytterhoeven wrote:
> [...]
> > When the "__nonstring" attributes are missing, the intent of the
> > programmer becomes ambiguous for whether the lack of a trailing NUL
> > in the p.small copy is a bug. Additionally, it's not clear whether
> > the trailing padding in the p.big copy is _needed_. Both cases
> > become unambiguous with:
> >
> > strtomem(p.small, "hello");
> > strtomem_pad(p.big, "hello");
> 
> strtomem_pad(p.big, "hello", 0);

Oops, thanks. I will adjust the example. And actually, instead of these
notes just living in commit logs, I realize I can update the kerndoc
for strncpy with a "here's now to pick a replacement" table...

> > See also https://github.com/KSPP/linux/issues/90
> >
> > Expand the memcpy KUnit tests to include these functions.
> >
> > Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > Cc: Nick Desaulniers <ndesaulniers@google.com>
> > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > Cc: Guenter Roeck <linux@roeck-us.net>
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> 
> The idea looks good to me, but I guess Linus has something to
> say, too.
> 
> > --- a/include/linux/string.h
> > +++ b/include/linux/string.h
> > @@ -260,6 +260,49 @@ static inline const char *kbasename(const char *path)
> >  void memcpy_and_pad(void *dest, size_t dest_len, const void *src, size_t count,
> >                     int pad);
> >
> > +/**
> > + * strtomem_pad - Copy NUL-terminated string to non-NUL-terminated buffer
> > + *
> > + * @dest: Pointer of destination character array (marked as __nonstring)
> > + * @src: Pointer to NUL-terminated string
> > + * @pad: Padding character to fill any remaining bytes of @dest after copy
> > + *
> > + * This is a replacement for strncpy() uses where the destination is not
> > + * a NUL-terminated string, but with bounds checking on the source size, and
> > + * an explicit padding character. If padding is not required, use strtomem().
> > + *
> > + * Note that the size of @dest is not an argument, as the length of @dest
> > + * must be discoverable by the compiler.
> > + */
> > +#define strtomem_pad(dest, src, pad)   do {                            \
> > +       const size_t _dest_len = __builtin_object_size(dest, 1);        \
> > +                                                                       \
> > +       BUILD_BUG_ON(!__builtin_constant_p(_dest_len) ||                \
> > +                    _dest_len == (size_t)-1);                          \
> 
> I think you want to include __must_be_array(dest) here.

I didn't do that for the cases where we may be writing to non-array
destinations (e.g. see the cast from u64 in the strncpy use in
tools/perf/arch/x86/util/intel-pt.c). Since what we need to know is the
object size, it does not strictly need to be an array.

> > [...]
> > +       memset(&wrap, 0xFF, sizeof(wrap));
> > +       KUNIT_EXPECT_EQ_MSG(test, wrap.canary1, -1UL,
> 
> -1L or ULONG_MAX (everywhere)

Yeah, ULONG_MAX looks best. Thanks!

> 
> > +                           "bad initial canary value");
> > +       KUNIT_EXPECT_EQ_MSG(test, wrap.canary2, -1UL,
> > +                           "bad initial canary value");
> > +
> > +       /* Check unpadded copy leaves surroundings untouched. */
> > +       strtomem(wrap.output, input);
> > +       KUNIT_EXPECT_EQ(test, wrap.canary1, -1UL);
> > +       KUNIT_EXPECT_EQ(test, wrap.output[0], input[0]);
> > +       KUNIT_EXPECT_EQ(test, wrap.output[1], input[1]);
> > +       for (int i = 2; i < sizeof(wrap.output); i++)
> 
> unsigned int i (everywhere)

I guess, but why? This could even be u8.

Thanks for the review!

-- 
Kees Cook

  reply	other threads:[~2022-09-01 18:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-31 23:00 [PATCH] string: Introduce strtomem() and strtomem_pad() Kees Cook
2022-09-01  8:39 ` Geert Uytterhoeven
2022-09-01 18:35   ` Kees Cook [this message]
2022-09-01 19:14     ` Geert Uytterhoeven
2022-09-01 19:23       ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202209011123.27D7D67@keescook \
    --to=keescook@chromium.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=ndesaulniers@google.com \
    --cc=pabeni@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=wsa+renesas@sang-engineering.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.