Messages in this thread | | | Subject | Re: [PATCH] crypto: testmgr - allocate buffers with __GFP_COMP | From | Robin Murphy <> | Date | Wed, 17 Apr 2019 10:54:39 +0100 |
| |
On 17/04/2019 09:09, Russell King - ARM Linux admin wrote: > On Tue, Apr 16, 2019 at 09:08:22PM -0700, Matthew Wilcox wrote: >> On Mon, Apr 15, 2019 at 10:14:51PM -0500, Kees Cook wrote: >>> On Mon, Apr 15, 2019 at 9:18 PM Matthew Wilcox <willy@infradead.org> wrote: >>>> I agree; if the crypto code is never going to try to go from the address of >>>> a byte in the allocation back to the head page, then there's no need to >>>> specify GFP_COMP. >>>> >>>> But that leaves us in the awkward situation where >>>> HARDENED_USERCOPY_PAGESPAN does need to be able to figure out whether >>>> 'ptr + n - 1' lies within the same allocation as ptr. Without using >>>> a compound page, there's no indication in the VM structures that these >>>> two pages were allocated as part of the same allocation. >>>> >>>> We could force all multi-page allocations to be compound pages if >>>> HARDENED_USERCOPY_PAGESPAN is enabled, but I worry that could break >>>> something. We could make it catch fewer problems by succeeding if the >>>> page is not compound. I don't know, these all seem like bad choices >>>> to me. >>> >>> If GFP_COMP is _not_ the correct signal about adjacent pages being >>> part of the same allocation, then I agree: we need to drop this check >>> entirely from PAGESPAN. Is there anything else that indicates this >>> property? (Or where might we be able to store that info?) >> >> As far as I know, the page allocator does not store size information >> anywhere, unless you use GFP_COMP. That's why you have to pass >> the 'order' to free_pages() and __free_pages(). It's also why >> alloc_pages_exact() works (follow all the way into split_page()). >> >>> There are other pagespan checks, though, so those could stay. But I'd >>> really love to gain page allocator allocation size checking ... >> >> I think that's a great idea, but I'm not sure how you'll be able to >> do that. > > However, we have had code (maybe historically now) that has allocated > a higher order page and then handed back pages that it doesn't need - > for example, when the code requires multiple contiguous pages but does > not require a power-of-2 size of contiguous pages.
'git grep alloc_pages_exact' suggests it's not historical yet...
Robin.
| |