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

2016-06-17 Thread Matt Fleming
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

2016-06-16 Thread Tom Lendacky
On 06/15/2016 08:17 AM, Tom Lendacky wrote: > On 06/13/2016 08:51 AM, Matt Fleming wrote: >> On Thu, 09 Jun, at 01:33:30PM, Tom Lendacky wrote: >>> [...] >> >>> I'll look further into this, but I saw that this area of virtual memory >>> was mapped un-encrypted and after freeing the boot services

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

2016-06-15 Thread Tom Lendacky
On 06/13/2016 08:51 AM, Matt Fleming wrote: > 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

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

2016-06-13 Thread Tom Lendacky
On 06/13/2016 07:03 AM, Matt Fleming wrote: > 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

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

2016-06-13 Thread Matt Fleming
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

2016-06-13 Thread Matt Fleming
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, > }; > > void __init * >

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

2016-06-13 Thread Matt Fleming
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

2016-06-09 Thread Tom Lendacky
On 06/08/2016 06:18 AM, Matt Fleming wrote: > 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

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

2016-06-09 Thread Tom Lendacky
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).

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

2016-06-08 Thread Matt Fleming
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

2016-06-08 Thread Matt Fleming
(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

2016-05-26 Thread Tom Lendacky
On 05/25/2016 02:30 PM, Matt Fleming wrote: > 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

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

2016-05-25 Thread Matt Fleming
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

2016-05-25 Thread Daniel Kiper
On Tue, May 24, 2016 at 09:54:31AM -0500, Tom Lendacky wrote: > On 05/12/2016 01:20 PM, Tom Lendacky wrote: > > On 05/10/2016 08:57 AM, Borislav Petkov wrote: > >> On Tue, May 10, 2016 at 02:43:58PM +0100, Matt Fleming wrote: > >>> Is it not possible to maintain some kind of kernel virtual address

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

2016-05-24 Thread Tom Lendacky
On 05/12/2016 01:20 PM, Tom Lendacky wrote: > On 05/10/2016 08:57 AM, Borislav Petkov wrote: >> On Tue, May 10, 2016 at 02:43:58PM +0100, Matt Fleming wrote: >>> Is it not possible to maintain some kind of kernel virtual address >>> mapping so memremap*() and friends can figure out when to twiddle

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

2016-05-12 Thread Tom Lendacky
On 05/10/2016 08:57 AM, Borislav Petkov wrote: > On Tue, May 10, 2016 at 02:43:58PM +0100, Matt Fleming wrote: >> Is it not possible to maintain some kind of kernel virtual address >> mapping so memremap*() and friends can figure out when to twiddle the >> mapping attributes and map with/without

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

2016-05-10 Thread Matt Fleming
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

2016-05-10 Thread Borislav Petkov
On Tue, May 10, 2016 at 02:43:58PM +0100, Matt Fleming wrote: > Is it not possible to maintain some kind of kernel virtual address > mapping so memremap*() and friends can figure out when to twiddle the > mapping attributes and map with/without encryption? I guess we can move the sme_* specific

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

2016-04-26 Thread Tom Lendacky
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 it can be overridden by an architecture specific routine.

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

2016-04-26 Thread Tom Lendacky
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 it can be overridden by an architecture specific routine.