From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752524AbcGOExh (ORCPT ); Fri, 15 Jul 2016 00:53:37 -0400 Received: from mail-wm0-f43.google.com ([74.125.82.43]:38204 "EHLO mail-wm0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751790AbcGOExe (ORCPT ); Fri, 15 Jul 2016 00:53:34 -0400 MIME-Version: 1.0 In-Reply-To: References: <1468446964-22213-1-git-send-email-keescook@chromium.org> <1468446964-22213-3-git-send-email-keescook@chromium.org> <20160714232019.GA28254@350D> <1468544658.30053.26.camel@redhat.com> <20160715014151.GA13944@balbir.ozlabs.ibm.com> From: Kees Cook Date: Thu, 14 Jul 2016 21:53:31 -0700 X-Google-Sender-Auth: Gh68NoukyY-FxL93uusGbxsR8Ak Message-ID: Subject: Re: [PATCH v2 02/11] mm: Hardened usercopy To: Balbir Singh Cc: Rik van Riel , LKML , Casey Schaufler , PaX Team , Brad Spengler , Russell King , Catalin Marinas , Will Deacon , Ard Biesheuvel , Benjamin Herrenschmidt , Michael Ellerman , Tony Luck , Fenghua Yu , "David S. Miller" , "x86@kernel.org" , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Andy Lutomirski , Borislav Petkov , Mathias Krause , Jan Kara , Vitaly Wool , Andrea Arcangeli , Dmitry Vyukov , Laura Abbott , "linux-arm-kernel@lists.infradead.org" , linux-ia64@vger.kernel.org, "linuxppc-dev@lists.ozlabs.org" , sparclinux , linux-arch , Linux-MM , "kernel-hardening@lists.openwall.com" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 14, 2016 at 9:05 PM, Kees Cook wrote: > On Thu, Jul 14, 2016 at 6:41 PM, Balbir Singh wrote: >> On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote: >>> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote: >>> >>> > > == >>> > > + ((unsigned long)end & (unsigned >>> > > long)PAGE_MASK))) >>> > > + return NULL; >>> > > + >>> > > + /* Allow if start and end are inside the same compound >>> > > page. */ >>> > > + endpage = virt_to_head_page(end); >>> > > + if (likely(endpage == page)) >>> > > + return NULL; >>> > > + >>> > > + /* Allow special areas, device memory, and sometimes >>> > > kernel data. */ >>> > > + if (PageReserved(page) && PageReserved(endpage)) >>> > > + return NULL; >>> > >>> > If we came here, it's likely that endpage > page, do we need to check >>> > that only the first and last pages are reserved? What about the ones >>> > in >>> > the middle? >>> >>> I think this will be so rare, we can get away with just >>> checking the beginning and the end. >>> >> >> But do we want to leave a hole where an aware user space >> can try a longer copy_* to avoid this check? If it is unlikely >> should we just bite the bullet and do the check for the entire >> range? > > I'd be okay with expanding the test -- it should be an extremely rare > situation already since the common Reserved areas (kernel data) will > have already been explicitly tested. > > What's the best way to do "next page"? Should it just be: > > for ( ; page <= endpage ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr) ) { > if (!PageReserved(page)) > return ""; > } > > return NULL; > > ? Er, I was testing the wrong thing. How about: /* * Reject if range is not Reserved (i.e. special or device memory), * since then the object spans several independently allocated pages. */ for (; ptr <= end ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr)) { if (!PageReserved(page)) return ""; } return NULL; -- Kees Cook Chrome OS & Brillo Security From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [PATCH v2 02/11] mm: Hardened usercopy Date: Thu, 14 Jul 2016 21:53:31 -0700 Message-ID: References: <1468446964-22213-1-git-send-email-keescook@chromium.org> <1468446964-22213-3-git-send-email-keescook@chromium.org> <20160714232019.GA28254@350D> <1468544658.30053.26.camel@redhat.com> <20160715014151.GA13944@balbir.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: Sender: sparclinux-owner@vger.kernel.org To: Balbir Singh Cc: Rik van Riel , LKML , Casey Schaufler , PaX Team , Brad Spengler , Russell King , Catalin Marinas , Will Deacon , Ard Biesheuvel , Benjamin Herrenschmidt , Michael Ellerman , Tony Luck , Fenghua Yu , "David S. Miller" , "x86@kernel.org" , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Andy Lutomirski , Borislav Petkov , Mathias Krause J List-Id: linux-arch.vger.kernel.org On Thu, Jul 14, 2016 at 9:05 PM, Kees Cook wrote: > On Thu, Jul 14, 2016 at 6:41 PM, Balbir Singh wrote: >> On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote: >>> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote: >>> >>> > > == >>> > > + ((unsigned long)end & (unsigned >>> > > long)PAGE_MASK))) >>> > > + return NULL; >>> > > + >>> > > + /* Allow if start and end are inside the same compound >>> > > page. */ >>> > > + endpage = virt_to_head_page(end); >>> > > + if (likely(endpage == page)) >>> > > + return NULL; >>> > > + >>> > > + /* Allow special areas, device memory, and sometimes >>> > > kernel data. */ >>> > > + if (PageReserved(page) && PageReserved(endpage)) >>> > > + return NULL; >>> > >>> > If we came here, it's likely that endpage > page, do we need to check >>> > that only the first and last pages are reserved? What about the ones >>> > in >>> > the middle? >>> >>> I think this will be so rare, we can get away with just >>> checking the beginning and the end. >>> >> >> But do we want to leave a hole where an aware user space >> can try a longer copy_* to avoid this check? If it is unlikely >> should we just bite the bullet and do the check for the entire >> range? > > I'd be okay with expanding the test -- it should be an extremely rare > situation already since the common Reserved areas (kernel data) will > have already been explicitly tested. > > What's the best way to do "next page"? Should it just be: > > for ( ; page <= endpage ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr) ) { > if (!PageReserved(page)) > return ""; > } > > return NULL; > > ? Er, I was testing the wrong thing. How about: /* * Reject if range is not Reserved (i.e. special or device memory), * since then the object spans several independently allocated pages. */ for (; ptr <= end ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr)) { if (!PageReserved(page)) return ""; } return NULL; -- Kees Cook Chrome OS & Brillo Security From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com ([74.125.82.51]:36644 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752426AbcGOExe (ORCPT ); Fri, 15 Jul 2016 00:53:34 -0400 Received: by mail-wm0-f51.google.com with SMTP id f126so11367506wma.1 for ; Thu, 14 Jul 2016 21:53:33 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1468446964-22213-1-git-send-email-keescook@chromium.org> <1468446964-22213-3-git-send-email-keescook@chromium.org> <20160714232019.GA28254@350D> <1468544658.30053.26.camel@redhat.com> <20160715014151.GA13944@balbir.ozlabs.ibm.com> From: Kees Cook Date: Thu, 14 Jul 2016 21:53:31 -0700 Message-ID: Subject: Re: [PATCH v2 02/11] mm: Hardened usercopy Content-Type: text/plain; charset=UTF-8 Sender: linux-arch-owner@vger.kernel.org List-ID: To: Balbir Singh Cc: Rik van Riel , LKML , Casey Schaufler , PaX Team , Brad Spengler , Russell King , Catalin Marinas , Will Deacon , Ard Biesheuvel , Benjamin Herrenschmidt , Michael Ellerman , Tony Luck , Fenghua Yu , "David S. Miller" , "x86@kernel.org" , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Andy Lutomirski , Borislav Petkov , Mathias Krause , Jan Kara , Vitaly Wool , Andrea Arcangeli , Dmitry Vyukov , Laura Abbott , "linux-arm-kernel@lists.infradead.org" , linux-ia64@vger.kernel.org, "linuxppc-dev@lists.ozlabs.org" , sparclinux , linux-arch , Linux-MM , "kernel-hardening@lists.openwall.com" Message-ID: <20160715045331.UJXhVOGCtrK_BTfTHsvP1NIXHTiEjNEbjgDI4blVKEk@z> On Thu, Jul 14, 2016 at 9:05 PM, Kees Cook wrote: > On Thu, Jul 14, 2016 at 6:41 PM, Balbir Singh wrote: >> On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote: >>> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote: >>> >>> > > == >>> > > + ((unsigned long)end & (unsigned >>> > > long)PAGE_MASK))) >>> > > + return NULL; >>> > > + >>> > > + /* Allow if start and end are inside the same compound >>> > > page. */ >>> > > + endpage = virt_to_head_page(end); >>> > > + if (likely(endpage == page)) >>> > > + return NULL; >>> > > + >>> > > + /* Allow special areas, device memory, and sometimes >>> > > kernel data. */ >>> > > + if (PageReserved(page) && PageReserved(endpage)) >>> > > + return NULL; >>> > >>> > If we came here, it's likely that endpage > page, do we need to check >>> > that only the first and last pages are reserved? What about the ones >>> > in >>> > the middle? >>> >>> I think this will be so rare, we can get away with just >>> checking the beginning and the end. >>> >> >> But do we want to leave a hole where an aware user space >> can try a longer copy_* to avoid this check? If it is unlikely >> should we just bite the bullet and do the check for the entire >> range? > > I'd be okay with expanding the test -- it should be an extremely rare > situation already since the common Reserved areas (kernel data) will > have already been explicitly tested. > > What's the best way to do "next page"? Should it just be: > > for ( ; page <= endpage ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr) ) { > if (!PageReserved(page)) > return ""; > } > > return NULL; > > ? Er, I was testing the wrong thing. How about: /* * Reject if range is not Reserved (i.e. special or device memory), * since then the object spans several independently allocated pages. */ for (; ptr <= end ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr)) { if (!PageReserved(page)) return ""; } return NULL; -- Kees Cook Chrome OS & Brillo Security From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Date: Fri, 15 Jul 2016 04:53:31 +0000 Subject: Re: [PATCH v2 02/11] mm: Hardened usercopy Message-Id: List-Id: References: <1468446964-22213-1-git-send-email-keescook@chromium.org> <1468446964-22213-3-git-send-email-keescook@chromium.org> <20160714232019.GA28254@350D> <1468544658.30053.26.camel@redhat.com> <20160715014151.GA13944@balbir.ozlabs.ibm.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Balbir Singh Cc: Rik van Riel , LKML , Casey Schaufler , PaX Team , Brad Spengler , Russell King , Catalin Marinas , Will Deacon , Ard Biesheuvel , Benjamin Herrenschmidt , Michael Ellerman , Tony Luck , Fenghua Yu , "David S. Miller" , "x86@kernel.org" , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Andy Lutomirski , Borislav Petkov , Mathias Krause , Jan Kara , Vitaly Wool , Andrea Arcangeli , Dmitry Vyukov , Laura Abbott , "linux-arm-kernel@lists.infradead.org" , linux-ia64@vger.kernel.org, "linuxppc-dev@lists.ozlabs.org" , sparclinux , linux-arch , Linux-MM , "kernel-hardening@lists.openwall.com" On Thu, Jul 14, 2016 at 9:05 PM, Kees Cook wrote: > On Thu, Jul 14, 2016 at 6:41 PM, Balbir Singh wrote: >> On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote: >>> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote: >>> >>> > > = >>> > > + ((unsigned long)end & (unsigned >>> > > long)PAGE_MASK))) >>> > > + return NULL; >>> > > + >>> > > + /* Allow if start and end are inside the same compound >>> > > page. */ >>> > > + endpage = virt_to_head_page(end); >>> > > + if (likely(endpage = page)) >>> > > + return NULL; >>> > > + >>> > > + /* Allow special areas, device memory, and sometimes >>> > > kernel data. */ >>> > > + if (PageReserved(page) && PageReserved(endpage)) >>> > > + return NULL; >>> > >>> > If we came here, it's likely that endpage > page, do we need to check >>> > that only the first and last pages are reserved? What about the ones >>> > in >>> > the middle? >>> >>> I think this will be so rare, we can get away with just >>> checking the beginning and the end. >>> >> >> But do we want to leave a hole where an aware user space >> can try a longer copy_* to avoid this check? If it is unlikely >> should we just bite the bullet and do the check for the entire >> range? > > I'd be okay with expanding the test -- it should be an extremely rare > situation already since the common Reserved areas (kernel data) will > have already been explicitly tested. > > What's the best way to do "next page"? Should it just be: > > for ( ; page <= endpage ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr) ) { > if (!PageReserved(page)) > return ""; > } > > return NULL; > > ? Er, I was testing the wrong thing. How about: /* * Reject if range is not Reserved (i.e. special or device memory), * since then the object spans several independently allocated pages. */ for (; ptr <= end ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr)) { if (!PageReserved(page)) return ""; } return NULL; -- Kees Cook Chrome OS & Brillo Security From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72]) by kanga.kvack.org (Postfix) with ESMTP id E60EB6B025E for ; Fri, 15 Jul 2016 00:53:33 -0400 (EDT) Received: by mail-wm0-f72.google.com with SMTP id r190so6658206wmr.0 for ; Thu, 14 Jul 2016 21:53:33 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com. [2a00:1450:400c:c09::234]) by mx.google.com with ESMTPS id s7si2893987wme.118.2016.07.14.21.53.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jul 2016 21:53:32 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id f65so11403901wmi.0 for ; Thu, 14 Jul 2016 21:53:32 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1468446964-22213-1-git-send-email-keescook@chromium.org> <1468446964-22213-3-git-send-email-keescook@chromium.org> <20160714232019.GA28254@350D> <1468544658.30053.26.camel@redhat.com> <20160715014151.GA13944@balbir.ozlabs.ibm.com> From: Kees Cook Date: Thu, 14 Jul 2016 21:53:31 -0700 Message-ID: Subject: Re: [PATCH v2 02/11] mm: Hardened usercopy Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Balbir Singh Cc: Rik van Riel , LKML , Casey Schaufler , PaX Team , Brad Spengler , Russell King , Catalin Marinas , Will Deacon , Ard Biesheuvel , Benjamin Herrenschmidt , Michael Ellerman , Tony Luck , Fenghua Yu , "David S. Miller" , "x86@kernel.org" , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Andy Lutomirski , Borislav Petkov , Mathias Krause , Jan Kara , Vitaly Wool , Andrea Arcangeli , Dmitry Vyukov , Laura Abbott , "linux-arm-kernel@lists.infradead.org" , linux-ia64@vger.kernel.org, "linuxppc-dev@lists.ozlabs.org" , sparclinux , linux-arch , Linux-MM , "kernel-hardening@lists.openwall.com" On Thu, Jul 14, 2016 at 9:05 PM, Kees Cook wrote: > On Thu, Jul 14, 2016 at 6:41 PM, Balbir Singh wrote: >> On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote: >>> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote: >>> >>> > > == >>> > > + ((unsigned long)end & (unsigned >>> > > long)PAGE_MASK))) >>> > > + return NULL; >>> > > + >>> > > + /* Allow if start and end are inside the same compound >>> > > page. */ >>> > > + endpage = virt_to_head_page(end); >>> > > + if (likely(endpage == page)) >>> > > + return NULL; >>> > > + >>> > > + /* Allow special areas, device memory, and sometimes >>> > > kernel data. */ >>> > > + if (PageReserved(page) && PageReserved(endpage)) >>> > > + return NULL; >>> > >>> > If we came here, it's likely that endpage > page, do we need to check >>> > that only the first and last pages are reserved? What about the ones >>> > in >>> > the middle? >>> >>> I think this will be so rare, we can get away with just >>> checking the beginning and the end. >>> >> >> But do we want to leave a hole where an aware user space >> can try a longer copy_* to avoid this check? If it is unlikely >> should we just bite the bullet and do the check for the entire >> range? > > I'd be okay with expanding the test -- it should be an extremely rare > situation already since the common Reserved areas (kernel data) will > have already been explicitly tested. > > What's the best way to do "next page"? Should it just be: > > for ( ; page <= endpage ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr) ) { > if (!PageReserved(page)) > return ""; > } > > return NULL; > > ? Er, I was testing the wrong thing. How about: /* * Reject if range is not Reserved (i.e. special or device memory), * since then the object spans several independently allocated pages. */ for (; ptr <= end ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr)) { if (!PageReserved(page)) return ""; } return NULL; -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: keescook@chromium.org (Kees Cook) Date: Thu, 14 Jul 2016 21:53:31 -0700 Subject: [PATCH v2 02/11] mm: Hardened usercopy In-Reply-To: References: <1468446964-22213-1-git-send-email-keescook@chromium.org> <1468446964-22213-3-git-send-email-keescook@chromium.org> <20160714232019.GA28254@350D> <1468544658.30053.26.camel@redhat.com> <20160715014151.GA13944@balbir.ozlabs.ibm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Jul 14, 2016 at 9:05 PM, Kees Cook wrote: > On Thu, Jul 14, 2016 at 6:41 PM, Balbir Singh wrote: >> On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote: >>> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote: >>> >>> > > == >>> > > + ((unsigned long)end & (unsigned >>> > > long)PAGE_MASK))) >>> > > + return NULL; >>> > > + >>> > > + /* Allow if start and end are inside the same compound >>> > > page. */ >>> > > + endpage = virt_to_head_page(end); >>> > > + if (likely(endpage == page)) >>> > > + return NULL; >>> > > + >>> > > + /* Allow special areas, device memory, and sometimes >>> > > kernel data. */ >>> > > + if (PageReserved(page) && PageReserved(endpage)) >>> > > + return NULL; >>> > >>> > If we came here, it's likely that endpage > page, do we need to check >>> > that only the first and last pages are reserved? What about the ones >>> > in >>> > the middle? >>> >>> I think this will be so rare, we can get away with just >>> checking the beginning and the end. >>> >> >> But do we want to leave a hole where an aware user space >> can try a longer copy_* to avoid this check? If it is unlikely >> should we just bite the bullet and do the check for the entire >> range? > > I'd be okay with expanding the test -- it should be an extremely rare > situation already since the common Reserved areas (kernel data) will > have already been explicitly tested. > > What's the best way to do "next page"? Should it just be: > > for ( ; page <= endpage ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr) ) { > if (!PageReserved(page)) > return ""; > } > > return NULL; > > ? Er, I was testing the wrong thing. How about: /* * Reject if range is not Reserved (i.e. special or device memory), * since then the object spans several independently allocated pages. */ for (; ptr <= end ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr)) { if (!PageReserved(page)) return ""; } return NULL; -- Kees Cook Chrome OS & Brillo Security From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com MIME-Version: 1.0 Sender: keescook@google.com In-Reply-To: References: <1468446964-22213-1-git-send-email-keescook@chromium.org> <1468446964-22213-3-git-send-email-keescook@chromium.org> <20160714232019.GA28254@350D> <1468544658.30053.26.camel@redhat.com> <20160715014151.GA13944@balbir.ozlabs.ibm.com> From: Kees Cook Date: Thu, 14 Jul 2016 21:53:31 -0700 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy To: Balbir Singh Cc: Rik van Riel , LKML , Casey Schaufler , PaX Team , Brad Spengler , Russell King , Catalin Marinas , Will Deacon , Ard Biesheuvel , Benjamin Herrenschmidt , Michael Ellerman , Tony Luck , Fenghua Yu , "David S. Miller" , "x86@kernel.org" , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Andy Lutomirski , Borislav Petkov , Mathias Krause , Jan Kara , Vitaly Wool , Andrea Arcangeli , Dmitry Vyukov , Laura Abbott , "linux-arm-kernel@lists.infradead.org" , linux-ia64@vger.kernel.org, "linuxppc-dev@lists.ozlabs.org" , sparclinux , linux-arch , Linux-MM , "kernel-hardening@lists.openwall.com" List-ID: On Thu, Jul 14, 2016 at 9:05 PM, Kees Cook wrote: > On Thu, Jul 14, 2016 at 6:41 PM, Balbir Singh wrote: >> On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote: >>> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote: >>> >>> > > == >>> > > + ((unsigned long)end & (unsigned >>> > > long)PAGE_MASK))) >>> > > + return NULL; >>> > > + >>> > > + /* Allow if start and end are inside the same compound >>> > > page. */ >>> > > + endpage = virt_to_head_page(end); >>> > > + if (likely(endpage == page)) >>> > > + return NULL; >>> > > + >>> > > + /* Allow special areas, device memory, and sometimes >>> > > kernel data. */ >>> > > + if (PageReserved(page) && PageReserved(endpage)) >>> > > + return NULL; >>> > >>> > If we came here, it's likely that endpage > page, do we need to check >>> > that only the first and last pages are reserved? What about the ones >>> > in >>> > the middle? >>> >>> I think this will be so rare, we can get away with just >>> checking the beginning and the end. >>> >> >> But do we want to leave a hole where an aware user space >> can try a longer copy_* to avoid this check? If it is unlikely >> should we just bite the bullet and do the check for the entire >> range? > > I'd be okay with expanding the test -- it should be an extremely rare > situation already since the common Reserved areas (kernel data) will > have already been explicitly tested. > > What's the best way to do "next page"? Should it just be: > > for ( ; page <= endpage ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr) ) { > if (!PageReserved(page)) > return ""; > } > > return NULL; > > ? Er, I was testing the wrong thing. How about: /* * Reject if range is not Reserved (i.e. special or device memory), * since then the object spans several independently allocated pages. */ for (; ptr <= end ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr)) { if (!PageReserved(page)) return ""; } return NULL; -- Kees Cook Chrome OS & Brillo Security