{"push_id":2319838830,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"fcb98f3425fed9bb05d81f22bda7f29cb4c8ab14","before":"736a2a1db40a3fb41f19d342d520ee14272ca7fb","commits":[{"sha":"fcb98f3425fed9bb05d81f22bda7f29cb4c8ab14","author":{"name":"jtl","email":"5a4310232d3032dace51fcd14379dd3cb74d04b7@FreeBSD.org"},"message":"On bootup, the amd64 pmap initialization code creates page-table\nmappings for the pages used for the kernel and some initial allocations\nused for the page table. It maps the kernel and the blocks used for\nthese initial allocations using 2MB pages.\n\nHowever, if the kernel does not end on a 2MB boundary, it still maps the\nlast portion using a 2MB page, but reports that the unused 4K blocks\nwithin this 2MB allocation are free physical blocks. This means that\nthese same physical blocks could also be mapped elsewhere - for example,\ninto a user process. Given the proximity to the kernel text and data\narea, it seems wise to avoid allowing someone to write data to physical\nblocks also mapped into these virtual addresses.\n\n(Note that this isn't a security vulnerability: the direct map makes\nmost/all memory on the system mapped into kernel space. And, nothing\nin the kernel should be trying to access these pages, as the virtual\naddresses are unused. It simply seems wise to avoid reusing these\nphysical blocks while they are mapped to virtual addresses so close\nto the kernel text and data area.)\n\nConsequently, let's reserve the physical blocks covered by the\npage-table mappings for these initial allocations.\n\nReviewed by:\tkib, markj\nMFC after:\t2 weeks\nSponsored by:\tNetflix\nDifferential Revision:\thttps://reviews.freebsd.org/D14268","distinct":true,"url":"https://api.github.com/repos/freebsd/freebsd/commits/fcb98f3425fed9bb05d81f22bda7f29cb4c8ab14"}]}
{"actor":{"display_login":"uqs"}}