On 09/15/2016 04:57 AM, Matt Fleming wrote: > On Wed, 14 Sep, at 09:20:44AM, Tom Lendacky wrote: >> On 09/12/2016 11:55 AM, Andy Lutomirski wrote: >>> On Aug 22, 2016 6:53 PM, "Tom Lendacky" <thomas.lendacky@xxxxxxx> wrote: >>>> >>>> BOOT data (such as EFI related data) is not encyrpted when the system is >>>> booted and needs to be accessed as non-encrypted. Add support to the >>>> early_memremap API to identify the type of data being accessed so that >>>> the proper encryption attribute can be applied. Currently, two types >>>> of data are defined, KERNEL_DATA and BOOT_DATA. >>> >>> What happens when you memremap boot services data outside of early >>> boot? Matt just added code that does this. >>> >>> IMO this API is not so great. It scatters a specialized consideration >>> all over the place. Could early_memremap not look up the PA to figure >>> out what to do? >> >> Yes, I could see if the PA falls outside of the kernel usable area and, >> if so, remove the memory encryption attribute from the mapping (for both >> early_memremap and memremap). >> >> Let me look into that, I would prefer something along that line over >> this change. > > So, the last time we talked about using the address to figure out > whether to encrypt/decrypt you said, > > "I looked into this and this would be a large change also to parse > tables and build lists." > > Has something changed that makes this approach easier? The original idea of parsing the tables and building a list was a large change. This approach would be simpler by just checking if the PA is outside the kernel usable area, and if so, removing the encryption bit. > > And again, you need to be careful with the EFI kexec code paths, since > you've got a mixture of boot and kernel data being passed. In > particular the EFI memory map is allocated by the firmware on first > boot (BOOT_DATA) but by the kernel on kexec (KERNEL_DATA). > > That's one of the reasons I suggested requiring the caller to decide > on BOOT_DATA vs KERNEL_DATA - when you start looking at kexec the > distinction isn't easily made. Yeah, for kexec I think I'll need to make sure that everything looks like it came from the BIOS/UEFI/bootloader. If all of the kexec pieces are allocated with un-encrypted memory, then the boot path should remain the same. That's the piece I need to investigate further. Thanks, Tom > -- 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
