[GIT PULL] EFI fixes

Linus, Please pull the latest efi-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-urgent-for-linus # HEAD: d1eb98143c56f24fef125f5bbed49ae0b52fb7d6 efi/arm: Fix boot crash with CONFIG_CPUMASK_OFFSTACK=y A boot crash fix, and a secure boot

Re: [PATCH 06/18] pstore: Extract common arguments into structure

On Tue, Mar 7, 2017 at 8:22 AM, Namhyung Kim wrote: > On Tue, Mar 7, 2017 at 6:55 AM, Kees Cook wrote: >> The read/mkfile pair pass the same arguments and should be cleared >> between calls. Move to a structure and wipe it after every loop. >> >>

Re: [PATCH V12 10/10] arm/arm64: KVM: add guest SEA support

Hi Tyler, On 06/03/17 20:45, Tyler Baicar wrote: > Currently external aborts are unsupported by the guest abort > handling. Add handling for SEAs so that the host kernel reports > SEAs which occur in the guest kernel. > diff --git a/arch/arm/include/asm/kvm_arm.h b/arch/arm/include/asm/kvm_arm.h

Re: [RFC PATCH v2 02/32] x86: Secure Encrypted Virtualization (SEV) support

On Thu, Mar 02, 2017 at 10:12:20AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Provide support for Secure Encyrpted Virtualization (SEV). This initial > support defines a flag that is used by the kernel to determine if it is > running with SEV active. > >

Re: [RFC PATCH v2 07/32] x86/efi: Access EFI data as encrypted when SEV is active

On Thu, Mar 02, 2017 at 10:13:21AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > EFI data is encrypted when the kernel is run under SEV. Update the > page table references to be sure the EFI memory areas are accessed > encrypted. > > Signed-off-by: Tom Lendacky

Re: [RFC PATCH v2 05/32] x86: Use encrypted access of BOOT related data with SEV

On Thu, Mar 02, 2017 at 10:12:59AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > When Secure Encrypted Virtualization (SEV) is active, BOOT data (such as > EFI related data, setup data) is encrypted and needs to be accessed as > such when mapped. Update the

Re: [PATCH V12 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64

Hi Tyler, On 06/03/17 20:44, Tyler Baicar wrote: > When a memory error, CPU error, PCIe error, or other type of hardware error > that's covered by RAS occurs, firmware should populate the shared GHES memory > location with the proper GHES structures to notify the OS of the error. > For example,

Re: [PATCH V12 05/10] acpi: apei: handle SEA notification type for ARMv8

Hi Tyler, On 06/03/17 20:44, Tyler Baicar wrote: > ARM APEI extension proposal added SEA (Synchronous External Abort) > notification type for ARMv8. > Add a new GHES error source handling function for SEA. If an error > source's notification type is SEA, then this function can be registered >

Re: [RFC PATCH v2 08/32] x86: Use PAGE_KERNEL protection for ioremap of memory page

On Thu, Mar 02, 2017 at 10:13:32AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > In order for memory pages to be properly mapped when SEV is active, we > need to use the PAGE_KERNEL protection attribute as the base protection. > This will insure that memory

Re: [PATCH 06/18] pstore: Extract common arguments into structure

On Tue, Mar 7, 2017 at 6:55 AM, Kees Cook wrote: > The read/mkfile pair pass the same arguments and should be cleared > between calls. Move to a structure and wipe it after every loop. > > Signed-off-by: Kees Cook > --- > fs/pstore/platform.c | 55

Re: [PATCH V12 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64

On 3/7/2017 4:37 AM, James Morse wrote: Hi Tyler, On 06/03/17 20:44, Tyler Baicar wrote: When a memory error, CPU error, PCIe error, or other type of hardware error that's covered by RAS occurs, firmware should populate the shared GHES memory location with the proper GHES structures to notify

Re: [PATCH V12 05/10] acpi: apei: handle SEA notification type for ARMv8

Hello James, On 3/7/2017 4:37 AM, James Morse wrote: On 06/03/17 20:44, Tyler Baicar wrote: ARM APEI extension proposal added SEA (Synchronous External Abort) notification type for ARMv8. Add a new GHES error source handling function for SEA. If an error source's notification type is SEA,

Re: [PATCH 03/18] pstore: Avoid race in module unloading

Hi Kees, On Tue, Mar 7, 2017 at 6:55 AM, Kees Cook wrote: > Technically, it might be possible for struct pstore_info to go out of > scope after the module_put(), so report the backend name first. But in that case, using pstore will crash the kernel anyway, right? If so,

Re: [PATCH 03/18] pstore: Avoid race in module unloading

On Tue, Mar 7, 2017 at 8:16 AM, Namhyung Kim wrote: > Hi Kees, > > On Tue, Mar 7, 2017 at 6:55 AM, Kees Cook wrote: >> Technically, it might be possible for struct pstore_info to go out of >> scope after the module_put(), so report the backend name

Re: [RFC PATCH v4 28/28] x86: Add support to make use of Secure Memory Encryption

On 3/1/2017 12:40 PM, Borislav Petkov wrote: On Thu, Feb 16, 2017 at 09:48:25AM -0600, Tom Lendacky wrote: This patch adds the support to check if SME has been enabled and if memory encryption should be activated (checking of command line option based on the configuration of the default state).

Re: [RFC PATCH v4 14/28] Add support to access boot related data in the clear

On 02/16/17 at 09:45am, Tom Lendacky wrote: [snip] > + * This function determines if an address should be mapped encrypted. > + * Boot setup data, EFI data and E820 areas are checked in making this > + * determination. > + */ > +static bool memremap_should_map_encrypted(resource_size_t phys_addr,

Re: [RFC PATCH v4 24/28] x86: Access the setup data through debugfs decrypted

On 02/16/17 at 09:47am, Tom Lendacky wrote: > Use memremap() to map the setup data. This simplifies the code and will > make the appropriate decision as to whether a RAM remapping can be done > or if a fallback to ioremap_cache() is needed (which includes checking > PageHighMem). > >

Re: [RFC PATCH v4 25/28] x86: Access the setup data through sysfs decrypted

On 02/16/17 at 09:47am, Tom Lendacky wrote: > Use memremap() to map the setup data. This will make the appropriate > decision as to whether a RAM remapping can be done or if a fallback to > ioremap_cache() is needed (similar to the setup data debugfs support). > > Signed-off-by: Tom Lendacky

[PATCH 2/2] x86/mm/KASLR: Correct the upper boundary of KALSR mm regions if adjacent to EFI

EFI allocates runtime services regions top-down, starting from EFI_VA_START to EFI_VA_END. So EFI_VA_START is bigger than EFI_VA_END and is the end of EFI region. The upper boundary of memory regions randomized by KASLR should be EFI_VA_END if it's adjacent to EFI region, but not EFI_VA_START.

[PATCH 1/2] x86/efi: Correct a tiny mistake in code comment

EFI allocate runtime services regions down from EFI_VA_START, -4G. It should be top-down handling. Signed-off-by: Baoquan He --- arch/x86/platform/efi/efi_64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/platform/efi/efi_64.c

Re: [PATCH V12 10/10] arm/arm64: KVM: add guest SEA support

Hello James, On 3/7/2017 4:48 AM, James Morse wrote: On 06/03/17 20:45, Tyler Baicar wrote: Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel. diff --git