On Mon, 12 Oct, at 05:34:53PM, Ard Biesheuvel wrote: > > On arm64, we only map in all of the UEFI runtime services regions > during the time any of these services are being invoked. I think this > should be mostly feasible on x86 as well, although it would involve > yet another rewrite of the EFI region mapping code, and most likely a > long list of quirks for platforms that are not able to deal with it > correctly for one reason or the other (but that all come down to: 'if > you are not doing it like Windows does it, you must be doing it > wrong'). Actually, we use separate page tables for mapping the EFI runtime services on x86 right now. These tables are only used when making runtime calls, just like on arm64. So we've got a little bit of isolation right now. > That would make the 'secure' way of mapping things an opt-in > feature, which is generally not desirable for security features > (since it will rarely be used in the real world then). I'd like to think that we're coming to EFI_PROPERTIES_TABLE early enough that we can work out all the kinks, get things working out of the box in upstream tianocore, and have it be the standard way to expose memory regions. At least that's my hope. > So enabling the Properties Table memprotect feature as soon as the > spec defines it in a meaningful way is probably a better way to go, > and our current involvement is focused on defining it such that it can > be enabled by default by firmwares rather than ending up an obscure > switch in the BIOS screen that only the paranoid ever turn on. Indeed. -- Matt Fleming, Intel Open Source Technology Center -- 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
