> On Apr 17, 2019, at 10:26 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > > * Nadav Amit <nadav.amit@xxxxxxxxx> wrote: > >>> On Apr 17, 2019, at 10:09 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote: >>> >>> >>> * Khalid Aziz <khalid.aziz@xxxxxxxxxx> wrote: >>> >>>>> I.e. the original motivation of the XPFO patches was to prevent execution >>>>> of direct kernel mappings. Is this motivation still present if those >>>>> mappings are non-executable? >>>>> >>>>> (Sorry if this has been asked and answered in previous discussions.) >>>> >>>> Hi Ingo, >>>> >>>> That is a good question. Because of the cost of XPFO, we have to be very >>>> sure we need this protection. The paper from Vasileios, Michalis and >>>> Angelos - <http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf>, >>>> does go into how ret2dir attacks can bypass SMAP/SMEP in sections 6.1 >>>> and 6.2. >>> >>> So it would be nice if you could generally summarize external arguments >>> when defending a patchset, instead of me having to dig through a PDF >>> which not only causes me to spend time that you probably already spent >>> reading that PDF, but I might also interpret it incorrectly. ;-) >>> >>> The PDF you cited says this: >>> >>> "Unfortunately, as shown in Table 1, the W^X prop-erty is not enforced >>> in many platforms, including x86-64. In our example, the content of >>> user address 0xBEEF000 is also accessible through kernel address >>> 0xFFFF87FF9F080000 as plain, executable code." >>> >>> Is this actually true of modern x86-64 kernels? We've locked down W^X >>> protections in general. >> >> As I was curious, I looked at the paper. Here is a quote from it: >> >> "In x86-64, however, the permissions of physmap are not in sane state. >> Kernels up to v3.8.13 violate the W^X property by mapping the entire region >> as “readable, writeable, and executable” (RWX)—only very recent kernels >> (≥v3.9) use the more conservative RW mapping.” > > But v3.8.13 is a 5+ years old kernel, it doesn't count as a "modern" > kernel in any sense of the word. For any proposed patchset with > significant complexity and non-trivial costs the benchmark version > threshold is the "current upstream kernel". > > So does that quote address my followup questions: > >> Is this actually true of modern x86-64 kernels? We've locked down W^X >> protections in general. >> >> I.e. this conclusion: >> >> "Therefore, by simply overwriting kfptr with 0xFFFF87FF9F080000 and >> triggering the kernel to dereference it, an attacker can directly >> execute shell code with kernel privileges." >> >> ... appears to be predicated on imperfect W^X protections on the x86-64 >> kernel. >> >> Do such holes exist on the latest x86-64 kernel? If yes, is there a >> reason to believe that these W^X holes cannot be fixed, or that any fix >> would be more expensive than XPFO? > > ? > > What you are proposing here is a XPFO patch-set against recent kernels > with significant runtime overhead, so my questions about the W^X holes > are warranted. > Just to clarify - I am an innocent bystander and have no part in this work. I was just looking (again) at the paper, as I was curious due to the recent patches that I sent that improve W^X protection.
