Re: [PATCH v7 19/36] x86/mm: Add support to access boot related data in the clear

- > arch/x86/include/asm/io.h |5 + > arch/x86/mm/ioremap.c | 179 > + > include/linux/io.h|2 + > kernel/memremap.c | 20 - > mm/early_ioremap.c| 18 - > 5 files

Re: [PATCH v7 18/36] x86/efi: Update EFI pagetable creation to work with SME

ov <b...@suse.de> > Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> > --- > arch/x86/platform/efi/efi_64.c | 15 +++ > 1 file changed, 11 insertions(+), 4 deletions(-) Reviewed-by: Matt Fleming <m...@codeblueprint.co.uk>

Re: [PATCH v7 16/36] efi: Add an EFI table address match function

> drivers/firmware/efi/efi.c | 33 + > include/linux/efi.h|7 +++ > 2 files changed, 40 insertions(+) Reviewed-by: Matt Fleming <m...@codeblueprint.co.uk> ___ iommu mailin

Re: [PATCH v7 17/36] efi: Update efi_mem_type() to return an error rather than 0

l/efi.c |4 ++-- > arch/x86/platform/efi/efi.c |6 +++--- > include/linux/efi.h |2 +- > 3 files changed, 6 insertions(+), 6 deletions(-) Reviewed-by: Matt Fleming <m...@codeblueprint.co.uk> _

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

On Mon, 15 May, at 08:35:17PM, Borislav Petkov wrote: > On Tue, Apr 18, 2017 at 04:19:21PM -0500, Tom Lendacky wrote: > > > + paddr = boot_params.efi_info.efi_memmap_hi; > > + paddr <<= 32; > > + paddr |= boot_params.efi_info.efi_memmap; > > + if (phys_addr

Re: [RFC PATCH v4 13/28] efi: Update efi_mem_type() to return defined EFI mem types

On Thu, 23 Feb, at 11:27:55AM, Tom Lendacky wrote: > > I can do that, I'll change the return type to an int. For the > !efi_enabled I can return -ENOTSUPP and for when an entry isn't > found I can return -EINVAL. Sound good? Sounds good to me! ___

Re: [RFC PATCH v4 13/28] efi: Update efi_mem_type() to return defined EFI mem types

On Thu, 16 Feb, at 09:44:57AM, Tom Lendacky wrote: > Update the efi_mem_type() to return EFI_RESERVED_TYPE instead of a > hardcoded 0. > > Signed-off-by: Tom Lendacky > --- > arch/x86/platform/efi/efi.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >

Re: [RFC PATCH v3 10/20] Add support to access boot related data in the clear

On Wed, 09 Nov, at 06:36:31PM, Tom Lendacky wrote: > Boot data (such as EFI related data) is not encrypted when the system is > booted and needs to be accessed unencrypted. Add support to apply the > proper attributes to the EFI page tables and to the early_memremap and > memremap APIs to

Re: [RFC PATCH v2 11/20] mm: Access BOOT related data in the clear

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" wrote: > >> > >> BOOT data (such as EFI related data) is not encyrpted when the system is > >> booted and needs to be accessed

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On Thu, 16 Jun, at 09:38:31AM, Tom Lendacky wrote: > > Ok, I think this was happening before the commit to build our own > EFI page table structures: > > commit 67a9108ed ("x86/efi: Build our own page table structures") > > Before this commit the boot services ended up mapped into the kernel >

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On Thu, 09 Jun, at 01:33:30PM, Tom Lendacky wrote: > > I was trying to play it safe here, but as you say, the firmware should > be using our page tables so we can get rid of this call. The problem > will actually be if we transition to a 32-bit efi. The encryption bit > will be lost in cr3 and so

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On Mon, 13 Jun, at 01:03:22PM, Matt Fleming wrote: > > Would we need a new function? Couldn't we just have a new > FIXMAP_PAGE_* constant? e.g. would something like this work? > > --- > > enum memremap_owner { > KERNEL_DATA = 0, > BOOT_DATA, > }; >

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On Thu, 09 Jun, at 11:16:40AM, Tom Lendacky wrote: > > 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. Sure, that works for me, though maybe BOOT_DATA would be more

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On Tue, 26 Apr, at 05:57:40PM, Tom Lendacky wrote: > The EFI tables are not encrypted and need to be accessed as such. Be sure > to memmap them without the encryption attribute set. For EFI support that > lives outside of the arch/x86 tree, create a routine that uses the __weak > attribute so that

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

(Sorry for the delay) 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

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On Tue, 24 May, at 09:54:31AM, Tom Lendacky wrote: > > I looked into this and this would be a large change also to parse tables > and build lists. It occurred to me that this could all be taken care of > if the early_memremap calls were changed to early_ioremap calls. Looking > in the git log I

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On Tue, 26 Apr, at 05:57:40PM, Tom Lendacky wrote: > The EFI tables are not encrypted and need to be accessed as such. Be sure > to memmap them without the encryption attribute set. For EFI support that > lives outside of the arch/x86 tree, create a routine that uses the __weak > attribute so that