linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: akpm@linux-foundation.org
Cc: Michal Hocko <mhocko@suse.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Kees Cook <keescook@chromium.org>,
	linux-mm@kvack.org,
	linux-kernel@vger.kernel.orgkeescook@chromium.org
Subject: [PATCH v2 0/3] Randomize free memory
Date: Wed, 03 Oct 2018 19:15:18 -0700	[thread overview]
Message-ID: <153861931865.2863953.11185006931458762795.stgit@dwillia2-desk3.amr.corp.intel.com> (raw)

Changes since v1:
* Add support for shuffling hot-added memory (Andrew)
* Update cover letter and commit message to clarify the performance impact
  and relevance to future platforms

[1]: https://lkml.org/lkml/2018/9/15/366

---

Some data exfiltration and return-oriented-programming attacks rely on
the ability to infer the location of sensitive data objects. The kernel
page allocator, especially early in system boot, has predictable
first-in-first out behavior for physical pages. Pages are freed in
physical address order when first onlined.

Quoting Kees:
    "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."

Another motivation for this change is performance in the presence of a
memory-side cache. In the future, memory-side-cache technology will be
available on generally available server platforms. The proposed
randomization approach has been measured to improve the cache conflict
rate by a factor of 2.5X on a well-known Java benchmark. It avoids
performance peaks and valleys to provide more predictable performance.

More details in the patch1 commit message.

---

Dan Williams (3):
      mm: Shuffle initial free memory
      mm: Move buddy list manipulations into helpers
      mm: Maintain randomization of page free lists


 include/linux/list.h     |   17 +++
 include/linux/mm.h       |    8 +
 include/linux/mm_types.h |    3 +
 include/linux/mmzone.h   |   57 ++++++++++
 mm/bootmem.c             |    9 +-
 mm/compaction.c          |    4 -
 mm/memory_hotplug.c      |    2 
 mm/nobootmem.c           |    7 +
 mm/page_alloc.c          |  267 +++++++++++++++++++++++++++++++++++++++-------
 9 files changed, 321 insertions(+), 53 deletions(-)

             reply	other threads:[~2018-10-04  2:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-04  2:15 Dan Williams [this message]
2018-10-04  2:15 ` [PATCH v2 1/3] mm: Shuffle initial " Dan Williams
2018-10-04  7:48   ` Michal Hocko
2018-10-04 16:51     ` Dan Williams
2018-10-09 11:12       ` Michal Hocko
2018-10-09 17:36         ` Dan Williams
2018-10-04  2:15 ` [PATCH v2 2/3] mm: Move buddy list manipulations into helpers Dan Williams
2018-10-04  2:15 ` [PATCH v2 3/3] mm: Maintain randomization of page free lists Dan Williams
2018-10-04  7:44 ` [PATCH v2 0/3] Randomize free memory Michal Hocko
2018-10-04 16:44   ` Dan Williams
2018-10-06 17:01     ` Dan Williams
2018-10-09 11:22     ` Michal Hocko
2018-10-09 17:34       ` Dan Williams
2018-10-10  8:47         ` Michal Hocko
2018-10-11  0:13           ` Dan Williams
2018-10-11 11:52             ` Michal Hocko
2018-10-11 18:03               ` Dan Williams
2018-10-18 13:44                 ` Michal Hocko
2018-10-12  8:22               ` Mel Gorman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=153861931865.2863953.11185006931458762795.stgit@dwillia2-desk3.amr.corp.intel.com \
    --to=dan.j.williams@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.orgkeescook \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox