From: Vlastimil Babka <vbabka@suse.cz>
To: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
Kees Cook <keescook@chromium.org>,
linux-mm@kvack.org, linux-hardening@vger.kernel.org,
patches@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/slab: remove HAVE_HARDENED_USERCOPY_ALLOCATOR
Date: Tue, 23 May 2023 09:46:46 +0200 [thread overview]
Message-ID: <623a87c6-c0d2-799a-c39e-0d14dcdfa6df@suse.cz> (raw)
In-Reply-To: <310077ed-6f3f-41fe-afcf-36500a9408ec@lucifer.local>
On 5/23/23 09:42, Lorenzo Stoakes wrote:
> On Tue, May 23, 2023 at 09:31:36AM +0200, Vlastimil Babka wrote:
>> With SLOB removed, both remaining allocators support hardened usercopy,
>> so remove the config and associated #ifdef.
>>
>> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>> ---
>> mm/Kconfig | 2 --
>> mm/slab.h | 9 ---------
>> security/Kconfig | 8 --------
>> 3 files changed, 19 deletions(-)
>>
>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index 7672a22647b4..041f0da42f2b 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -221,7 +221,6 @@ choice
>> config SLAB
>> bool "SLAB"
>> depends on !PREEMPT_RT
>> - select HAVE_HARDENED_USERCOPY_ALLOCATOR
>> help
>> The regular slab allocator that is established and known to work
>> well in all environments. It organizes cache hot objects in
>> @@ -229,7 +228,6 @@ config SLAB
>>
>> config SLUB
>> bool "SLUB (Unqueued Allocator)"
>> - select HAVE_HARDENED_USERCOPY_ALLOCATOR
>> help
>> SLUB is a slab allocator that minimizes cache line usage
>> instead of managing queues of cached objects (SLAB approach).
>> diff --git a/mm/slab.h b/mm/slab.h
>> index f01ac256a8f5..695ef96b4b5b 100644
>> --- a/mm/slab.h
>> +++ b/mm/slab.h
>> @@ -832,17 +832,8 @@ struct kmem_obj_info {
>> void __kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab);
>> #endif
>>
>> -#ifdef CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR
>> void __check_heap_object(const void *ptr, unsigned long n,
>> const struct slab *slab, bool to_user);
>> -#else
>> -static inline
>> -void __check_heap_object(const void *ptr, unsigned long n,
>> - const struct slab *slab, bool to_user)
>> -{
>> -}
>> -#endif
>
> Hm, this is still defined in slab.c/slub.c and invoked in usercopy.c, do we
> not want the prototype?
Well I didn't delete the prototype, just the ifdef/else around, so now it's
there unconditionally.
> Perhaps replacing with #ifdef
> CONFIG_HARDENED_USERCOPY instead? I may be missing something here :)
Putting it under that #ifdef would work and match that the implementations
of that function are under that same ifdef, but maybe it's unnecessary noise
in the header?
next prev parent reply other threads:[~2023-05-23 7:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-23 7:31 [PATCH] mm/slab: remove HAVE_HARDENED_USERCOPY_ALLOCATOR Vlastimil Babka
2023-05-23 7:42 ` Lorenzo Stoakes
2023-05-23 7:46 ` Vlastimil Babka [this message]
2023-05-23 7:56 ` Lorenzo Stoakes
2023-05-23 8:14 ` David Hildenbrand
2023-05-23 8:19 ` Lorenzo Stoakes
2023-05-23 8:28 ` David Hildenbrand
2023-05-24 7:15 ` Lorenzo Stoakes
2023-05-23 17:02 ` Kees Cook
2023-05-24 0:31 ` David Rientjes
2023-05-24 6:15 ` Hyeonggon Yoo
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=623a87c6-c0d2-799a-c39e-0d14dcdfa6df@suse.cz \
--to=vbabka@suse.cz \
--cc=42.hyeyoo@gmail.com \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=patches@lists.linux.dev \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
/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.