Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

On 3/16/2017 5:16 AM, Borislav Petkov wrote: On Fri, Mar 10, 2017 at 10:35:30AM -0600, Brijesh Singh wrote: We could update this patch to use the below logic: * CPUID(0) - Check for AuthenticAMD * CPID(1) - Check if under hypervisor * CPUID(0x8000) - Check for highest supported leaf *

RE: [PATCH] efi/arm32-stub: allow boottime allocations in the vmlinux region

> NOTE: This patch appears to have uncovered a bug in DxeCore's > AllocatePages routine. If the first > allocate_pages(EFI_ALLOCATE_ADDRESS) call fails, we may still end up > with a memory map that reflects a kind of limbo state where the intended > allocation is carved out and partially

[PATCH 4.10 19/48] efi/arm: Fix boot crash with CONFIG_CPUMASK_OFFSTACK=y

4.10-stable review patch. If anyone has any objections, please let me know. -- From: Ard Biesheuvel commit d1eb98143c56f24fef125f5bbed49ae0b52fb7d6 upstream. On ARM and arm64, we use a dedicated mm_struct to map the UEFI Runtime Services regions,

Re: kexec regression since 4.9 caused by efi

On Thu, Mar 16, 2017 at 12:41:32PM +, Matt Fleming wrote: > On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote: > > > > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is > > not > > correct to be used in efi_arch_mem_reserve, if it passed your test, I > > can rewrite

Re: [RFC PATCH v2 32/32] x86: kvm: Pin the guest memory when SEV is active

On 03/16/2017 05:38 AM, Paolo Bonzini wrote: On 02/03/2017 16:18, Brijesh Singh wrote: The SEV memory encryption engine uses a tweak such that two identical plaintexts at different location will have a different ciphertexts. So swapping or moving ciphertexts of two pages will not result in

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On Fri, Mar 10, 2017 at 04:41:56PM -0600, Brijesh Singh wrote: > I can take a look at fixing those warning. In my initial attempt was to create > a new function to clear encryption bit but it ended up looking very similar to > __change_page_attr_set_clr() hence decided to extend the exiting

Re: [RFC PATCH v2 30/32] kvm: svm: Add support for SEV DEBUG_ENCRYPT command

On 03/16/2017 06:03 AM, Paolo Bonzini wrote: On 02/03/2017 16:18, Brijesh Singh wrote: + data = (void *) get_zeroed_page(GFP_KERNEL); The page does not need to be zeroed, does it? No, we don't have to zero it. I will fix it. + + if ((len & 15) || (dst_addr & 15)) { +

Re: [RFC PATCH v2 26/32] kvm: svm: Add support for SEV LAUNCH_UPDATE_DATA command

On 03/16/2017 05:48 AM, Paolo Bonzini wrote: On 02/03/2017 16:17, Brijesh Singh wrote: +static struct page **sev_pin_memory(unsigned long uaddr, unsigned long ulen, + unsigned long *n) +{ + struct page **pages; + int first, last; + unsigned

Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

On Thu, Mar 16, 2017 at 11:11:26AM -0500, Tom Lendacky wrote: > Not quite. The guest still needs to understand about the encryption mask > so that it can protect memory by setting the encryption mask in the > pagetable entries. It can also decide when to share memory with the > hypervisor by not

Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

On Thu, Mar 16, 2017 at 09:28:58AM -0500, Tom Lendacky wrote: > Because there are differences between how SME and SEV behave > (instruction fetches are always decrypted under SEV, DMA to an > encrypted location is not supported under SEV, etc.) we need to > determine which mode we are in so that

Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

On 3/16/2017 10:09 AM, Borislav Petkov wrote: On Thu, Mar 16, 2017 at 09:28:58AM -0500, Tom Lendacky wrote: Because there are differences between how SME and SEV behave (instruction fetches are always decrypted under SEV, DMA to an encrypted location is not supported under SEV, etc.) we need to

[PATCH] efi/libstub: skip GOP with PIXEL_BLT_ONLY format

From: "Cohen, Eugene" The UEFI Specification permits Graphics Output Protocol (GOP) instances without direct framebuffer access. This is indicated in the Mode structure with a PixelFormat enumeration value of PIXEL_BLT_ONLY. Given that the kernel does not know how to drive a Blt()

Re: [PATCH v7 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size

* Thomas Garnier wrote: > This patch aligns MODULES_END to the beginning of the Fixmap section. > It optimizes the space available for both sections. The address is > pre-computed based on the number of pages required by the Fixmap > section. > > It will allow GDT

Re: kexec regression since 4.9 caused by efi

On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote: > > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not > correct to be used in efi_arch_mem_reserve, if it passed your test, I > can rewrite patch log with more background and send it out: > >

Re: kexec regression since 4.9 caused by efi

On Thu, 09 Mar, at 12:53:36PM, Ard Biesheuvel wrote: > > Hi Omar, > > Thanks for tracking this down. > > I wonder if this is an unintended side effect of the way we repurpose > the EFI_MEMORY_RUNTIME attribute in efi_arch_mem_reserve(). AFAIUI, > splitting memory map entries should only be

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On 02/03/2017 16:15, Brijesh Singh wrote: > > __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address, > -struct page *base) > + pte_t *pbase, unsigned long new_pfn) > { > - pte_t *pbase = (pte_t *)page_address(base); Just one comment and

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

On 3/7/2017 5:09 AM, Borislav Petkov wrote: 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

Re: [RFC PATCH v2 29/32] kvm: svm: Add support for SEV DEBUG_DECRYPT command

On 03/16/2017 05:54 AM, Paolo Bonzini wrote: On 02/03/2017 16:18, Brijesh Singh wrote: +static int __sev_dbg_decrypt_page(struct kvm *kvm, unsigned long src, + void *dst, int *error) +{ + inpages = sev_pin_memory(src, PAGE_SIZE, ); + if (!inpages) { +

Re: [PATCH] efi/arm32-stub: allow boottime allocations in the vmlinux region

On 16 March 2017 at 21:56, Roy Franz wrote: > On Thu, Mar 16, 2017 at 4:26 AM, Leif Lindholm > wrote: >> On Thu, Mar 16, 2017 at 10:56:16AM +, Ard Biesheuvel wrote: >>> The arm32 kernel decompresses itself to the base of DRAM unconditionally, >>>

Re: [PATCH] efi/arm32-stub: allow boottime allocations in the vmlinux region

On Thu, Mar 16, 2017 at 4:26 AM, Leif Lindholm wrote: > On Thu, Mar 16, 2017 at 10:56:16AM +, Ard Biesheuvel wrote: >> The arm32 kernel decompresses itself to the base of DRAM unconditionally, >> and so it is the EFI stub's job to ensure that the region is available.

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On 16/03/2017 19:28, Borislav Petkov wrote: > So how hard would it be if the hypervisor allocated that memory for the > guest instead? It would allocate it decrypted and guest would need to > access it decrypted too. All in preparation for SEV-ES which will need a > block of unencrypted memory

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On 10/03/2017 23:41, Brijesh Singh wrote: >> Maybe there's a reason this fires: >> >> WARNING: modpost: Found 2 section mismatch(es). >> To see full details build your kernel with: >> 'make CONFIG_DEBUG_SECTION_MISMATCH=y' >> >> WARNING: vmlinux.o(.text+0x48edc): Section mismatch in reference

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

On 3/7/2017 8:59 AM, Borislav Petkov wrote: 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

Re: [PATCH] efi/arm32-stub: allow boottime allocations in the vmlinux region

On Thu, Mar 16, 2017 at 3:02 PM, Ard Biesheuvel wrote: > On 16 March 2017 at 21:56, Roy Franz wrote: >> On Thu, Mar 16, 2017 at 4:26 AM, Leif Lindholm >> wrote: >>> On Thu, Mar 16, 2017 at 10:56:16AM +, Ard Biesheuvel

Re: [PATCH] efi/arm32-stub: allow boottime allocations in the vmlinux region

On 16 March 2017 at 23:07, Roy Franz wrote: > On Thu, Mar 16, 2017 at 3:02 PM, Ard Biesheuvel > wrote: >> On 16 March 2017 at 21:56, Roy Franz wrote: >>> On Thu, Mar 16, 2017 at 4:26 AM, Leif Lindholm

Re: [RFC PATCH v2 26/32] kvm: svm: Add support for SEV LAUNCH_UPDATE_DATA command

On 02/03/2017 16:17, Brijesh Singh wrote: > +static struct page **sev_pin_memory(unsigned long uaddr, unsigned long ulen, > + unsigned long *n) > +{ > + struct page **pages; > + int first, last; > + unsigned long npages, pinned; > + > + /* Get

[PATCH] efi/arm32-stub: allow boottime allocations in the vmlinux region

The arm32 kernel decompresses itself to the base of DRAM unconditionally, and so it is the EFI stub's job to ensure that the region is available. Currently, we do this by creating an allocation there, and giving up if that fails. However, any boot services regions occupying this area are not an

Re: [RFC PATCH v2 30/32] kvm: svm: Add support for SEV DEBUG_ENCRYPT command

On 02/03/2017 16:18, Brijesh Singh wrote: > + data = (void *) get_zeroed_page(GFP_KERNEL); The page does not need to be zeroed, does it? > + > + if ((len & 15) || (dst_addr & 15)) { > + /* if destination address and length are not 16-byte > + * aligned then: >

Re: [PATCH] efi/arm32-stub: allow boottime allocations in the vmlinux region

On Thu, Mar 16, 2017 at 10:56:16AM +, Ard Biesheuvel wrote: > The arm32 kernel decompresses itself to the base of DRAM unconditionally, > and so it is the EFI stub's job to ensure that the region is available. > > Currently, we do this by creating an allocation there, and giving up if > that

Re: [PATCH] efi/arm32-stub: allow boottime allocations in the vmlinux region

On 16 March 2017 at 11:26, Leif Lindholm wrote: > On Thu, Mar 16, 2017 at 10:56:16AM +, Ard Biesheuvel wrote: >> The arm32 kernel decompresses itself to the base of DRAM unconditionally, >> and so it is the EFI stub's job to ensure that the region is available. >> >>

Re: [PATCH V2] x86/efi: Add missing 1:1 mappings to support buggy firmware

On Tue, 28 Feb, at 07:25:34PM, Sai Praneeth Prakhya wrote: > > > > > > > I don't think we should be adding yet another place in the EFI code > > > where we're modifying the page tables. > > > > > > We already have the ability to map EFI_CONVENTIONAL_MEMORY regions > > > inside of

Re: [RFC PATCH v2 23/32] kvm: introduce KVM_MEMORY_ENCRYPT_OP ioctl

On 02/03/2017 16:17, Brijesh Singh wrote: > If hardware supports encrypting then KVM_MEMORY_ENCRYPT_OP ioctl can > be used by qemu to issue platform specific memory encryption commands. > > Signed-off-by: Brijesh Singh > --- > arch/x86/include/asm/kvm_host.h |2 ++ >

Re: [RFC PATCH v2 16/32] x86: kvm: Provide support to create Guest and HV shared per-CPU variables

On 02/03/2017 16:15, Brijesh Singh wrote: > Some KVM specific MSR's (steal-time, asyncpf, avic_eio) allocates per-CPU > variable at compile time and share its physical address with hypervisor. > It presents a challege when SEV is active in guest OS. When SEV is active, > guest memory is

Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

On Fri, Mar 10, 2017 at 10:35:30AM -0600, Brijesh Singh wrote: > We could update this patch to use the below logic: > > * CPUID(0) - Check for AuthenticAMD > * CPID(1) - Check if under hypervisor > * CPUID(0x8000) - Check for highest supported leaf > * CPUID(0x801F).EAX - Check for

Re: [RFC PATCH v2 24/32] kvm: x86: prepare for SEV guest management API support

On 02/03/2017 16:17, Brijesh Singh wrote: > ASID management: > - Reserve asid range for SEV guest, SEV asid range is obtained through >CPUID Fn8000_001f[ECX]. A non-SEV guest can use any asid outside the SEV >asid range. How is backwards compatibility handled? > - SEV guest must have

Re: [RFC PATCH v2 32/32] x86: kvm: Pin the guest memory when SEV is active

On 02/03/2017 16:18, Brijesh Singh wrote: > The SEV memory encryption engine uses a tweak such that two identical > plaintexts at different location will have a different ciphertexts. > So swapping or moving ciphertexts of two pages will not result in > plaintexts being swapped. Relocating (or