Messages in this thread | | | Subject | Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear | From | Tom Lendacky <> | Date | Thu, 9 Jun 2016 11:16:40 -0500 |
| |
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. >
| |