On 4/17/19 10:15 AM, Ingo Molnar wrote: > > [ Sorry, had to trim the Cc: list from hell. Tried to keep all the > mailing lists and all x86 developers. ] > > * Khalid Aziz <khalid.aziz@xxxxxxxxxx> wrote: > >> From: Juerg Haefliger <juerg.haefliger@xxxxxxxxxxxxx> >> >> This patch adds basic support infrastructure for XPFO which protects >> against 'ret2dir' kernel attacks. The basic idea is to enforce >> exclusive ownership of page frames by either the kernel or userspace, >> unless explicitly requested by the kernel. Whenever a page destined for >> userspace is allocated, it is unmapped from physmap (the kernel's page >> table). When such a page is reclaimed from userspace, it is mapped back >> to physmap. Individual architectures can enable full XPFO support using >> this infrastructure by supplying architecture specific pieces. > > I have a higher level, meta question: > > Is there any updated analysis outlining why this XPFO overhead would be > required on x86-64 kernels running on SMAP/SMEP CPUs which should be all > recent Intel and AMD CPUs, and with kernel that mark all direct kernel > mappings as non-executable - which should be all reasonably modern > kernels later than v4.0 or so? > > 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. Thanks, Khalid
