On Mon, Sep 17, 2018 at 4:12 PM, Andrew Morton <a...@linux-foundation.org> wrote: > On Sat, 15 Sep 2018 09:23:02 -0700 Dan Williams <dan.j.willi...@intel.com> > wrote: > >> Data exfiltration attacks via speculative execution and >> return-oriented-programming attacks rely on the ability to infer the >> location of sensitive data objects. The kernel page allocator, has >> predictable first-in-first-out behavior for physical pages. Pages are >> freed in physical address order when first onlined. There are also >> mechanisms like CMA that can free large contiguous areas at once >> increasing the predictability of allocations in physical memory. >> >> In addition to the security implications this randomization also >> stabilizes the average performance of direct-mapped memory-side caches. >> This includes memory-side caches like the one on the Knights Landing >> processor and those generally described by the ACPI HMAT (Heterogeneous >> Memory Attributes Table [1]). Cache conflicts are spread over a random >> distribution rather than localized. >> >> Given the performance sensitivity of the page allocator this >> randomization is only performed for MAX_ORDER (4MB by default) pages. A >> kernel parameter, page_alloc.shuffle_page_order, is included to change >> the page size where randomization occurs. >> >> [1]: See ACPI 6.2 Section 5.2.27.5 Memory Side Cache Information Structure > > I'm struggling to understand the justification of all of this. Are > such attacks known to exist? Or reasonably expected to exist in the > future? What is the likelihood and what is their cost? Or is this all > academic and speculative and possibly pointless?
While we already have a base-address randomization (CONFIG_RANDOMIZE_MEMORY), attacks against the same hardware and memory layouts would certainly be using the predictability of allocation ordering (i.e. for attacks where the base address isn't important: only the relative positions between allocated memory). This is common in lots of heap-style attacks. They try to gain control over ordering by spraying allocations, etc. I'd really like to see this because it gives us something similar to CONFIG_SLAB_FREELIST_RANDOM but for the page allocator. (This may be worth mentioning in the series, especially as a comparison to its behavior and this.) > ie, something must have motivated you to do this work rather than > <something-else>. Please spell out that motivation. I'd be curious to hear more about the mentioned cache performance improvements. I love it when a security feature actually _improves_ performance. :) Thanks for working on this! -Kees -- Kees Cook Pixel Security
