On 06/08/2016 05:07 AM, Matt Fleming wrote: > (Sorry for the delay) No worries, thanks for all the feedback. > > On Thu, 26 May, at 08:45:58AM, Tom Lendacky wrote: >> >> The patch in question is patch 6/18 where PAGE_KERNEL is changed to >> include the _PAGE_ENC attribute (the encryption mask). This now >> makes FIXMAP_PAGE_NORMAL contain the encryption mask while >> FIXMAP_PAGE_IO does not. In this way, anything mapped using the >> early_ioremap call won't be mapped encrypted. > > There are semantics attached to early_ioremap() that do not apply in > this case; that you're mapping an MMIO region but for EFI we just care > about noting where the firmware (not the kernel) populated the region > with data. Similar problems exist for other early boot code such as > the devicetree stuff. > > early_ioremap() is not the answer. > > What you really want is just some way to distinguish kernel-owned > regions from those owned by "somebody else". > > I have no problem updating early_memremap() to take a @flags argument > to make that distinction, provided that the naming is generic and not > tied to AMD's SME technology via an "sme" prefix/suffix. So maybe something along the lines of an enum that would have entries (initially) like KERNEL_DATA (equal to zero) and EFI_DATA. Others could be added later as needed. Would you then want to allow the protection attributes to be updated by architecture specific code through something like a __weak function? In the x86 case I can add this function as a non-SME specific function that would initially just have the SME-related mask modification in it. Thanks, Tom > > And making it generic should allow it to be easily sprinkled into the > shared architecture code in drivers/firmware/efi/ without issue. > > I'm going to follow up with some additional comments/questions on > PATCH 10. > -- 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
