From mboxrd@z Thu Jan 1 00:00:00 1970 From: labbott@redhat.com (Laura Abbott) Date: Wed, 20 Jul 2016 08:36:38 -0700 Subject: [PATCH v3 02/11] mm: Hardened usercopy In-Reply-To: <1469010283.2800.5.camel@gmail.com> References: <1468619065-3222-1-git-send-email-keescook@chromium.org> <1468619065-3222-3-git-send-email-keescook@chromium.org> <1469010283.2800.5.camel@gmail.com> Message-ID: <2aabe10d-2ccb-2ba6-18bb-b7f52d70d36c@redhat.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 07/20/2016 03:24 AM, Balbir Singh wrote: > On Tue, 2016-07-19 at 11:48 -0700, Kees Cook wrote: >> On Mon, Jul 18, 2016 at 6:06 PM, Laura Abbott wrote: >>> >>> On 07/15/2016 02:44 PM, Kees Cook wrote: >>> >>> This doesn't work when copying CMA allocated memory since CMA purposely >>> allocates larger than a page block size without setting head pages. >>> Given CMA may be used with drivers doing zero copy buffers, I think it >>> should be permitted. >>> >>> Something like the following lets it pass (I can clean up and submit >>> the is_migrate_cma_page APIs as a separate patch for review) >> Yeah, this would be great. I'd rather use an accessor to check this >> than a direct check for MIGRATE_CMA. >> >>> */ >>> for (; ptr <= end ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr)) >>> { >>> - if (!PageReserved(page)) >>> + if (!PageReserved(page) && !is_migrate_cma_page(page)) >>> return ""; >>> } >> Yeah, I'll modify this a bit so that which type it starts as is >> maintained for all pages (rather than allowing to flip back and forth >> -- even though that is likely impossible). >> > Sorry, I completely missed the MIGRATE_CMA bits. Could you clarify if you > caught this in testing/review? > > Balbir Singh. > I caught it while looking at the code and then wrote a test case to confirm I was correct because I wasn't sure how to easily find an in tree user. Thanks, Laura