On 1/11/19 2:06 PM, Andy Lutomirski wrote: > On Fri, Jan 11, 2019 at 12:42 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: >> >>>> The second process could easily have the page's old TLB entry. It could >>>> abuse that entry as long as that CPU doesn't context switch >>>> (switch_mm_irqs_off()) or otherwise flush the TLB entry. >>> >>> That is an interesting scenario. Working through this scenario, physmap >>> TLB entry for a page is flushed on the local processor when the page is >>> allocated to userspace, in xpfo_alloc_pages(). When the userspace passes >>> page back into kernel, that page is mapped into kernel space using a va >>> from kmap pool in xpfo_kmap() which can be different for each new >>> mapping of the same page. The physical page is unmapped from kernel on >>> the way back from kernel to userspace by xpfo_kunmap(). So two processes >>> on different CPUs sharing same physical page might not be seeing the >>> same virtual address for that page while they are in the kernel, as long >>> as it is an address from kmap pool. ret2dir attack relies upon being >>> able to craft a predictable virtual address in the kernel physmap for a >>> physical page and redirect execution to that address. Does that sound right? >> >> All processes share one set of kernel page tables. Or, did your patches >> change that somehow that I missed? >> >> Since they share the page tables, they implicitly share kmap*() >> mappings. kmap_atomic() is not *used* by more than one CPU, but the >> mapping is accessible and at least exists for all processors. >> >> I'm basically assuming that any entry mapped in a shared page table is >> exploitable on any CPU regardless of where we logically *want* it to be >> used. >> >> > > We can, very easily, have kernel mappings that are private to a given > mm. Maybe this is useful here. > That sounds like an interesting idea. kmap mappings would be a good candidate for that. Those are temporary mappings and should only be valid for one process. -- Khalid
Attachment:
pEpkey.asc
Description: application/pgp-keys
