netdev - Re: [PATCH -next 1/2] string.h: Introduce memset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 9 Dec 2021 14:29:26 +0800
From:   xiujianfeng <xiujianfeng@...wei.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
CC:     <keescook@...omium.org>, <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


在 2021/12/9 7:44, Andrew Morton 写道:
> 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.
that is good, thank you for you advice :)
>
>>>> + *
>>>> + */
>>>> +#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.

#define offsetofend(TYPE, MEMBER) \
              (offsetof(TYPE, MEMBER)>+ sizeof_field(TYPE, MEMBER))

if I understand correctly, offsetofend(typeof(*(a), d) is 12, so it 
expands to

     memset(__ptr + 4, __val,

                   12 -

                   4);

Anyway,  I will drop this patch because of Kees's suggestion, thank you.

> .