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@xxxxxxxxxxxxx> 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.
