From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Borntraeger Subject: Re: [kernel-hardening] [PATCH 09/38] usercopy: Mark kmalloc caches as usercopy caches Date: Tue, 7 Apr 2020 13:05:46 +0200 Message-ID: References: <201911121313.1097D6EE@keescook> <201911141327.4DE6510@keescook> <202001271519.AA6ADEACF0@keescook> <5861936c-1fe1-4c44-d012-26efa0c8b6e7@de.ibm.com> <202001281457.FA11CC313A@keescook> <6844ea47-8e0e-4fb7-d86f-68046995a749@de.ibm.com> <20200129170939.GA4277@infradead.org> <771c5511-c5ab-3dd1-d938-5dbc40396daa@de.ibm.com> <202001300945.7D465B5F5@keescook> <7d810f6d-8085-ea2f-7805-47ba3842dc50@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:57556 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726591AbgDGLGN (ORCPT ); Tue, 7 Apr 2020 07:06:13 -0400 Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 037B4YpE060430 for ; Tue, 7 Apr 2020 07:06:11 -0400 Received: from e06smtp04.uk.ibm.com (e06smtp04.uk.ibm.com [195.75.94.100]) by mx0b-001b2d01.pphosted.com with ESMTP id 308eu865sp-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 07 Apr 2020 07:06:11 -0400 Received: from localhost by e06smtp04.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 7 Apr 2020 12:05:45 +0100 In-Reply-To: <7d810f6d-8085-ea2f-7805-47ba3842dc50@suse.cz> Content-Language: en-US Sender: linux-arch-owner@vger.kernel.org List-ID: To: Vlastimil Babka , Jann Horn , Kees Cook Cc: Christoph Hellwig , Christopher Lameter , Jiri Slaby , Julian Wiedmann , Ursula Braun , Alexander Viro , kernel list , David Windsor , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Linux-MM , linux-xfs@vger.kernel.org, Linus Torvalds , Andy Lutomirski , "David S. Miller" , Laura Abbott , Mark Rutland , "Martin K. Petersen" On 07.04.20 10:00, Vlastimil Babka wrote: > On 1/31/20 1:03 PM, Jann Horn wrote: > >> I think dma-kmalloc slabs should be handled the same way as normal >> kmalloc slabs. When a dma-kmalloc allocation is freshly created, it is >> just normal kernel memory - even if it might later be used for DMA -, >> and it should be perfectly fine to copy_from_user() into such >> allocations at that point, and to copy_to_user() out of them at the >> end. If you look at the places where such allocations are created, you >> can see things like kmemdup(), memcpy() and so on - all normal >> operations that shouldn't conceptually be different from usercopy in >> any relevant way. > > So, let's do that? > > ----8<---- > From d5190e4e871689a530da3c3fd327be45a88f006a Mon Sep 17 00:00:00 2001 > From: Vlastimil Babka > Date: Tue, 7 Apr 2020 09:58:00 +0200 > Subject: [PATCH] usercopy: Mark dma-kmalloc caches as usercopy caches > > We have seen a "usercopy: Kernel memory overwrite attempt detected to SLUB > object 'dma-kmalloc-1 k' (offset 0, size 11)!" error on s390x, as IUCV uses > kmalloc() with __GFP_DMA because of memory address restrictions. > The issue has been discussed [2] and it has been noted that if all the kmalloc > caches are marked as usercopy, there's little reason not to mark dma-kmalloc > caches too. The 'dma' part merely means that __GFP_DMA is used to restrict > memory address range. > > As Jann Horn put it [3]: > > "I think dma-kmalloc slabs should be handled the same way as normal > kmalloc slabs. When a dma-kmalloc allocation is freshly created, it is > just normal kernel memory - even if it might later be used for DMA -, > and it should be perfectly fine to copy_from_user() into such > allocations at that point, and to copy_to_user() out of them at the > end. If you look at the places where such allocations are created, you > can see things like kmemdup(), memcpy() and so on - all normal > operations that shouldn't conceptually be different from usercopy in > any relevant way." > > Thus this patch marks the dma-kmalloc-* caches as usercopy. > > [1] https://bugzilla.suse.com/show_bug.cgi?id=1156053 > [2] https://lore.kernel.org/kernel-hardening/bfca96db-bbd0-d958-7732-76e36c667c68@suse.cz/ > [3] https://lore.kernel.org/kernel-hardening/CAG48ez1a4waGk9kB0WLaSbs4muSoK0AYAVk8=XYaKj4_+6e6Hg@mail.gmail.com/ > > Signed-off-by: Vlastimil Babka Acked-by: Christian Borntraeger > --- > mm/slab_common.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/mm/slab_common.c b/mm/slab_common.c > index 5282f881d2f5..ae9486160594 100644 > --- a/mm/slab_common.c > +++ b/mm/slab_common.c > @@ -1303,7 +1303,8 @@ void __init create_kmalloc_caches(slab_flags_t flags) > kmalloc_caches[KMALLOC_DMA][i] = create_kmalloc_cache( > kmalloc_info[i].name[KMALLOC_DMA], > kmalloc_info[i].size, > - SLAB_CACHE_DMA | flags, 0, 0); > + SLAB_CACHE_DMA | flags, 0, > + kmalloc_info[i].size); > } > } > #endif > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:57556 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726591AbgDGLGN (ORCPT ); Tue, 7 Apr 2020 07:06:13 -0400 Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 037B4YpE060430 for ; Tue, 7 Apr 2020 07:06:11 -0400 Received: from e06smtp04.uk.ibm.com (e06smtp04.uk.ibm.com [195.75.94.100]) by mx0b-001b2d01.pphosted.com with ESMTP id 308eu865sp-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 07 Apr 2020 07:06:11 -0400 Received: from localhost by e06smtp04.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 7 Apr 2020 12:05:45 +0100 Subject: Re: [kernel-hardening] [PATCH 09/38] usercopy: Mark kmalloc caches as usercopy caches References: <201911121313.1097D6EE@keescook> <201911141327.4DE6510@keescook> <202001271519.AA6ADEACF0@keescook> <5861936c-1fe1-4c44-d012-26efa0c8b6e7@de.ibm.com> <202001281457.FA11CC313A@keescook> <6844ea47-8e0e-4fb7-d86f-68046995a749@de.ibm.com> <20200129170939.GA4277@infradead.org> <771c5511-c5ab-3dd1-d938-5dbc40396daa@de.ibm.com> <202001300945.7D465B5F5@keescook> <7d810f6d-8085-ea2f-7805-47ba3842dc50@suse.cz> From: Christian Borntraeger Date: Tue, 7 Apr 2020 13:05:46 +0200 MIME-Version: 1.0 In-Reply-To: <7d810f6d-8085-ea2f-7805-47ba3842dc50@suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Message-ID: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Vlastimil Babka , Jann Horn , Kees Cook Cc: Christoph Hellwig , Christopher Lameter , Jiri Slaby , Julian Wiedmann , Ursula Braun , Alexander Viro , kernel list , David Windsor , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Linux-MM , linux-xfs@vger.kernel.org, Linus Torvalds , Andy Lutomirski , "David S. Miller" , Laura Abbott , Mark Rutland , "Martin K. Petersen" , Paolo Bonzini , Christoffer Dall , Dave Kleikamp , Jan Kara , Luis de Bethencourt , Marc Zyngier , Rik van Riel , Matthew Garrett , linux-fsdevel , linux-arch , Network Development , Kernel Hardening , Michal Kubecek Message-ID: <20200407110546.ENBeafNJrUp3UZZ8jN6oN0V_mF1Z9eZjkoviRfsuD7E@z> On 07.04.20 10:00, Vlastimil Babka wrote: > On 1/31/20 1:03 PM, Jann Horn wrote: > >> I think dma-kmalloc slabs should be handled the same way as normal >> kmalloc slabs. When a dma-kmalloc allocation is freshly created, it is >> just normal kernel memory - even if it might later be used for DMA -, >> and it should be perfectly fine to copy_from_user() into such >> allocations at that point, and to copy_to_user() out of them at the >> end. If you look at the places where such allocations are created, you >> can see things like kmemdup(), memcpy() and so on - all normal >> operations that shouldn't conceptually be different from usercopy in >> any relevant way. > > So, let's do that? > > ----8<---- > From d5190e4e871689a530da3c3fd327be45a88f006a Mon Sep 17 00:00:00 2001 > From: Vlastimil Babka > Date: Tue, 7 Apr 2020 09:58:00 +0200 > Subject: [PATCH] usercopy: Mark dma-kmalloc caches as usercopy caches > > We have seen a "usercopy: Kernel memory overwrite attempt detected to SLUB > object 'dma-kmalloc-1 k' (offset 0, size 11)!" error on s390x, as IUCV uses > kmalloc() with __GFP_DMA because of memory address restrictions. > The issue has been discussed [2] and it has been noted that if all the kmalloc > caches are marked as usercopy, there's little reason not to mark dma-kmalloc > caches too. The 'dma' part merely means that __GFP_DMA is used to restrict > memory address range. > > As Jann Horn put it [3]: > > "I think dma-kmalloc slabs should be handled the same way as normal > kmalloc slabs. When a dma-kmalloc allocation is freshly created, it is > just normal kernel memory - even if it might later be used for DMA -, > and it should be perfectly fine to copy_from_user() into such > allocations at that point, and to copy_to_user() out of them at the > end. If you look at the places where such allocations are created, you > can see things like kmemdup(), memcpy() and so on - all normal > operations that shouldn't conceptually be different from usercopy in > any relevant way." > > Thus this patch marks the dma-kmalloc-* caches as usercopy. > > [1] https://bugzilla.suse.com/show_bug.cgi?id=1156053 > [2] https://lore.kernel.org/kernel-hardening/bfca96db-bbd0-d958-7732-76e36c667c68@suse.cz/ > [3] https://lore.kernel.org/kernel-hardening/CAG48ez1a4waGk9kB0WLaSbs4muSoK0AYAVk8=XYaKj4_+6e6Hg@mail.gmail.com/ > > Signed-off-by: Vlastimil Babka Acked-by: Christian Borntraeger > --- > mm/slab_common.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/mm/slab_common.c b/mm/slab_common.c > index 5282f881d2f5..ae9486160594 100644 > --- a/mm/slab_common.c > +++ b/mm/slab_common.c > @@ -1303,7 +1303,8 @@ void __init create_kmalloc_caches(slab_flags_t flags) > kmalloc_caches[KMALLOC_DMA][i] = create_kmalloc_cache( > kmalloc_info[i].name[KMALLOC_DMA], > kmalloc_info[i].size, > - SLAB_CACHE_DMA | flags, 0, 0); > + SLAB_CACHE_DMA | flags, 0, > + kmalloc_info[i].size); > } > } > #endif >