On 03/16/17 at 12:41pm, 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 patch log with more b
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
>>> wrote:
On Thu, Mar 16, 2017 at 10:56:16AM +, Ard Biesheuvel wrote:
> The arm
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 wrote:
The arm32 kernel decompresses itself to the base of DRAM unco
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 fo
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.
>>
>> Currently, we do thi
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,
>>> and so it is the EFI stub's job to ensure tha
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 protection.
This will insure that me
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 as
such when mapped. Update
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, &npages);
+ if (!inpages) {
+
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)) {
+
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 functio
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
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
p
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 pat
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 s
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
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 th
4.9-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, which allows us to map those re
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, which allows us to map those r
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
* C
> 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 conver
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 fro
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:
>
> for_each_efi_memory
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
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 neces
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 efi_map_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.
>>
>> Currently, we do this by c
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 f
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 encrypted
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:
> +
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 is
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, &npages);
> + if (!inpages) {
> + ret = -ENOMEM;
> + goto err
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 numbe
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 mi
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
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 ++
> arch/x86/kvm/x86.c
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 SME
* 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 remapping in the Fixmap sectio
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() only framebuffe
39 matches
Mail list logo