FreeBSD/src ad4fcb0 (r332822)sys/amd64/amd64 pmap.c

MFC r329071:
  On bootup, the amd64 pmap initialization code creates page-table
  mappings for the pages used for the kernel and some initial allocations
  used for the page table. It maps the kernel and the blocks used for
  these initial allocations using 2MB pages.

  However, if the kernel does not end on a 2MB boundary, it still maps the
  last portion using a 2MB page, but reports that the unused 4K blocks
  within this 2MB allocation are free physical blocks. This means that
  these same physical blocks could also be mapped elsewhere - for example,
  into a user process. Given the proximity to the kernel text and data
  area, it seems wise to avoid allowing someone to write data to physical
  blocks also mapped into these virtual addresses.

  (Note that this isn't a security vulnerability: the direct map makes
  most/all memory on the system mapped into kernel space. And, nothing
  in the kernel should be trying to access these pages, as the virtual
  addresses are unused. It simply seems wise to avoid reusing these
  physical blocks while they are mapped to virtual addresses so close
  to the kernel text and data area.)

  Consequently, let's reserve the physical blocks covered by the
  page-table mappings for these initial allocations.

Sponsored by:   Netflix, Inc.
DeltaFile
+7-0sys/amd64/amd64/pmap.c
+7-01 files

UnifiedSplitRaw