On Wed, Oct 21, 2015 at 1:45 PM, Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 21 Oct, at 11:46:53AM, Andy Lutomirski wrote: >> >> If the UEFI stuff is mapped in its own PGD entry, we could just RO >> that entire PGD entry everywhere except the UEFI pgd (and make sure to >> clear G so that the TLB entries get zapped). > > What would be the benefit of making it RO as opposed to not having it > mapped at all? Nothing. > The mappings only exist in the trampoline_pgd right now > for x86 which minimizes the potentially vulnerable code paths to the > EFI runtime calls and the suspend/resume code. Oh, I didn't realize it. So what's the problem here? Honestly, while UEFI is full of questionable things, I don't really see how an unprivileged user program should be able to cause malicious input to be send to UEFI code, so it should be quite difficult to exploit a buffer overflow or other errant write in UEFI to escalate privileges from user to anything else. (Kernel -> SMM escalation is a whole different story, but preventing that is SMM's business, not the kernel's. I've actually been a wee bit tempted to write a /dev/smram driver to expose SMRAM using a portfolio of old known exploits.) --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
