]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
On bootup, the amd64 pmap initialization code creates page-table
authorJonathan T. Looney <jtl@FreeBSD.org>
Fri, 9 Feb 2018 17:46:33 +0000 (17:46 +0000)
committerJonathan T. Looney <jtl@FreeBSD.org>
Fri, 9 Feb 2018 17:46:33 +0000 (17:46 +0000)
commit31ba4c7b5bb7ff42f55942c71a1baa2cb399598d
tree0e1827d39143d29153e2f41b29a7e80d99a80584
parentad4bbe575b9d6f50debda6ecd1fb9a77770e179e
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.

Reviewed by: kib, markj
MFC after: 2 weeks
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D14268
sys/amd64/amd64/pmap.c