[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202112082111.14E796A23@keescook>
Date: Wed, 8 Dec 2021 21:17:44 -0800
From: Kees Cook <keescook@...omium.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: xiujianfeng <xiujianfeng@...wei.com>,
laniel_francis@...vacyrequired.com,
andriy.shevchenko@...ux.intel.com, adobriyan@...il.com,
linux@...ck-us.net, andreyknvl@...il.com, dja@...ens.net,
ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
kafai@...com, songliubraving@...com, yhs@...com,
john.fastabend@...il.com, kpsingh@...nel.org,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
bpf@...r.kernel.org
Subject: Re: [PATCH -next 1/2] string.h: Introduce memset_range() for wiping
members
On Wed, Dec 08, 2021 at 03:44:37PM -0800, Andrew Morton wrote:
> On Wed, 8 Dec 2021 18:30:26 +0800 xiujianfeng <xiujianfeng@...wei.com> wrote:
>
> >
> > 在 2021/12/8 12:28, Andrew Morton 写道:
> > > On Wed, 8 Dec 2021 11:04:50 +0800 Xiu Jianfeng <xiujianfeng@...wei.com> wrote:
> > >
> > >> Motivated by memset_after() and memset_startat(), introduce a new helper,
> > >> memset_range() that takes the target struct instance, the byte to write,
> > >> and two member names where zeroing should start and end.
> > > Is this likely to have more than a single call site?
> > There maybe more call site for this function, but I just use bpf as an
> > example.
> > >
> > >> ...
> > >>
> > >> --- a/include/linux/string.h
> > >> +++ b/include/linux/string.h
> > >> @@ -291,6 +291,26 @@ void memcpy_and_pad(void *dest, size_t dest_len, const void *src, size_t count,
> > >> sizeof(*(obj)) - offsetof(typeof(*(obj)), member)); \
> > >> })
> > >>
> > >> +/**
> > >> + * memset_range - Set a value ranging from member1 to member2, boundary included.
> > > I'm not sure what "boundary included" means.
> > I mean zeroing from member1 to member2(including position indicated by
> > member1 and member2)
> > >
> > >> + *
> > >> + * @obj: Address of target struct instance
> > >> + * @v: Byte value to repeatedly write
> > >> + * @member1: struct member to start writing at
> > >> + * @member2: struct member where writing should stop
> > > Perhaps "struct member before which writing should stop"?
> > memset_range should include position indicated by member2 as well
>
> In that case we could say "struct member where writing should stop
> (inclusive)", to make it very clear.
>
> > >
> > >> + *
> > >> + */
> > >> +#define memset_range(obj, v, member_1, member_2) \
> > >> +({ \
> > >> + u8 *__ptr = (u8 *)(obj); \
> > >> + typeof(v) __val = (v); \
> > >> + BUILD_BUG_ON(offsetof(typeof(*(obj)), member_1) > \
> > >> + offsetof(typeof(*(obj)), member_2)); \
> > >> + memset(__ptr + offsetof(typeof(*(obj)), member_1), __val, \
> > >> + offsetofend(typeof(*(obj)), member_2) - \
> > >> + offsetof(typeof(*(obj)), member_1)); \
> > >> +})
> > > struct a {
> > > int b;
> > > int c;
> > > int d;
> > > };
> > >
> > > How do I zero out `c' and `d'?
> > if you want to zero out 'c' and 'd', you can use it like
> > memset_range(a_ptr, c, d);
>
> But I don't think that's what the code does!
>
> it expands to
>
> memset(__ptr + offsetof(typeof(*(a)), c), __val,
> offsetofend(typeof(*(a)), d) -
> offsetof(typeof(*(a)), c));
>
> which expands to
>
> memset(__ptr + 4, __val,
> 8 -
> 4);
>
> and `d' will not be written to.
Please don't add memset_range(): just use a struct_group() to capture
the range and use memset() against the new substruct. This will allow
for the range to be documented where it is defined in the struct (rather
than deep in some code), keep any changes centralized instead of spread
around in memset_range() calls, protect against accidental struct member
reordering breaking things, and lets the compiler be able to examine
the range explicitly and do all the correct bounds checking:
struct a {
int b;
struct_group(range,
int c;
int d;
);
int e;
};
memset(&instance->range, 0, sizeof(instance->range));
memset_from/after() were added because of the very common case of "wipe
from here to end", which stays tied to a single member, and addressed
cases where struct_group() couldn't help (e.g. trailing padding).
--
Kees Cook
Powered by blists - more mailing lists