On 1/16/19 7:56 AM, Julian Stecklina wrote: > Khalid Aziz <khalid.aziz@xxxxxxxxxx> writes: > >> I am continuing to build on the work Juerg, Tycho and Julian have done >> on XPFO. > > Awesome! > >> A rogue process can launch a ret2dir attack only from a CPU that has >> dual mapping for its pages in physmap in its TLB. We can hence defer >> TLB flush on a CPU until a process that would have caused a TLB flush >> is scheduled on that CPU. > > Assuming the attacker already has the ability to execute arbitrary code > in userspace, they can just create a second process and thus avoid the > TLB flush. Am I getting this wrong? No, you got it right. The patch I wrote closes the security hole when attack is launched from the same process but still leaves a window open when attack is launched from another process. I am working on figuring out how to close that hole while keeping the performance the same as it is now. Synchronous TLB flush across all cores is the most secure but performance impact is horrendous. -- Khalid
Attachment:
pEpkey.asc
Description: application/pgp-keys
