Hi Ard,
On 07/11/2018 05:00 AM, Ard Biesheuvel wrote:
On 3 July 2018 at 15:32, Brijesh Singh wrote:
SEV guest fails to update the UEFI runtime variables stored in the
flash. commit 1379edd59673 ("x86/efi: Access EFI data as encrypted
when SEV is active") unconditionally maps al
On 7/3/18 10:44 AM, Borislav Petkov wrote:
> (dropping stable@ as this is not how you send patches to stable).
>
> On Tue, Jul 03, 2018 at 05:37:18PM +0200, Ard Biesheuvel wrote:
>> On 3 July 2018 at 15:32, Brijesh Singh wrote:
>>> SEV guest fails to update the UEFI
Cc: Matt Fleming
Cc: Andy Lutomirski
Cc: # 4.15.x
Signed-off-by: Brijesh Singh
---
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 b/arch/x86/platform/efi/efi_64.c
index 77873ce..5f2eb32 100644
--- a/arch/x86/pl
From: Tom Lendacky <thomas.lenda...@amd.com>
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 <thomas.lenda...@amd.com>
Signed-off-by: Brijesh Singh <brijes
x...@kernel.org
Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com>
Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
Reviewed-by: Borislav Petkov <b...@suse.de>
---
arch/x86/platform/efi/efi_64.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff -
x...@kernel.org
Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com>
Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
Reviewed-by: Borislav Petkov <b...@suse.de>
---
arch/x86/platform/efi/efi_64.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff -
x...@kernel.org
Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com>
Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
---
arch/x86/platform/efi/efi_64.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/pl
On 09/15/2017 11:22 AM, Borislav Petkov wrote:
mem_encrypt_init() where everything should be set up already.
Yep, its safe to derefs the static key in mem_encrypt_init(). I've
tried the approach and it seems to be work fine. I will include the
required changes in next rev. thanks
--
To
On 09/15/2017 09:40 AM, Borislav Petkov wrote:
I need to figure out the include hell first.
I am working with slightly newer patch sets -- in that patch Tom has
moved the sev_active() definition in arch/x86/mm/mem_encrypt.c and I
have no issue using your recommended (since I no longer need
On 09/15/2017 07:24 AM, Borislav Petkov wrote:
On Tue, Aug 22, 2017 at 06:52:48PM +0200, Borislav Petkov wrote:
As always, the devil is in the detail.
Ok, actually we can make this much simpler by using a static key. A
conceptual patch below - I only need to fix that crazy include hell I'm
On 9/4/17 12:05 PM, Borislav Petkov wrote:
> On Fri, Sep 01, 2017 at 05:52:13PM -0500, Brijesh Singh wrote:
>> So far, we have not seen the need for having such functions except
>> this cases. The approach we have right now works just fine and not
>> sure if its worth
On 9/1/17 10:21 PM, Andy Lutomirski wrote:
> On Fri, Sep 1, 2017 at 3:52 PM, Brijesh Singh <brijesh.si...@amd.com> wrote:
>> Hi Boris,
>>
>> On 08/30/2017 12:46 PM, Borislav Petkov wrote:
>>> On Wed, Aug 30, 2017 at 11:18:42AM -0500, Brijesh Singh wrote:
>
Hi Boris,
On 08/30/2017 12:46 PM, Borislav Petkov wrote:
On Wed, Aug 30, 2017 at 11:18:42AM -0500, Brijesh Singh wrote:
I was trying to avoid mixing early and no-early set_memory_decrypted() but if
feedback is: use early_set_memory_decrypted() only if its required otherwise
use
Hi Boris,
On 08/29/2017 05:22 AM, Borislav Petkov wrote:
[...]
On Mon, Jul 24, 2017 at 02:07:56PM -0500, Brijesh Singh wrote:
Some KVM specific MSR's (steal-time, asyncpf, avic_eio) allocates per-CPU
MSRs
variable at compile time and share its physical address
Hi Boris,
On 8/28/17 5:51 AM, Borislav Petkov wrote:
[..]
> +static int __init early_set_memory_enc_dec(resource_size_t paddr,
>> + unsigned long size, bool enc)
>> +{
>> +unsigned long vaddr, vaddr_end, vaddr_next;
>> +unsigned long psize, pmask;
On 07/26/2017 02:26 PM, H. Peter Anvin wrote:
\
static inline void outs##bwl(int port, const void *addr, unsigned
long count) \
{
This will clash with a fix I did to add a "memory" clobber
for the traditional
Hi Arnd and David,
On 07/26/2017 05:45 AM, Arnd Bergmann wrote:
On Tue, Jul 25, 2017 at 11:51 AM, David Laight <david.lai...@aculab.com> wrote:
From: Brijesh Singh
Sent: 24 July 2017 20:08
From: Tom Lendacky <thomas.lenda...@amd.com>
Secure Encrypted Virtualization (SEV) does
From: Tom Lendacky <thomas.lenda...@amd.com>
Secure Encrypted Virtualization (SEV) does not support string I/O, so
unroll the string I/O operation into a loop operating on one element at
a time.
Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com>
Signed-off-by: Brijesh Singh
ertain things are handled: e.g. DMA (always bounce
buffered with SEV) or EFI tables (always access decrypted with SME).
Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com>
Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
---
arch/x86/boot/compressed/Makefile | 2 +
arch/x
hypervisor and guest can access the data.
Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
---
arch/x86/entry/vdso/vma.c | 5 ++--
arch/x86/kernel/kvmclock.c | 64 +++---
2 files changed, 58 insertions(+), 11 deletions(-)
diff --git a/arch/x86
code.
Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
---
arch/x86/include/asm/mem_encrypt.h | 17 ++
arch/x86/mm/mem_encrypt.c | 117 +
2 files changed, 134 insertions(+)
diff --git a/arch/x86/include/asm/mem_encrypt.h
b/arch/x86/inclu
map this section without C-bit.
This patch implements #3. It introduces a new DEFINE_PER_CPU_HV_SHAHRED
macro to create a compile time per-CPU variable. When SEV is detected we
clear the C-bit from the shared per-CPU variable.
Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
---
ar
Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com>
Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
---
arch/x86/mm/ioremap.c | 28
include/linux/ioport.h | 3 +++
kernel/resource.c | 17 +
3 files changed, 48 insertions(+)
dif
source structure, the callback functions can obtain
them from the resource structure directly.
Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com>
Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
---
arch/powerpc/kernel/machine_kexec_file_64.c | 12 +---
arch/
d code.
Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com>
Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
---
kernel/resource.c | 53 ++---
1 file changed, 26 insertions(+), 27 deletions(-)
diff --git a/kernel/resource.c b/kerne
From: Tom Lendacky <thomas.lenda...@amd.com>
When SEV is active the trampoline area will need to be in encrypted
memory so only mark the area decrypted if SME is active.
Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com>
Signed-off-by: Brijesh Singh <brijesh.si...@amd.com
e when mapping this data.
Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com>
Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
---
arch/x86/mm/ioremap.c | 44
1 file changed, 32 insertions(+), 12 deletions(-)
diff --git a/arch/x86/mm/io
ndacky <thomas.lenda...@amd.com>
Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
---
arch/x86/mm/pageattr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index dfb7d65..b726b23 100644
--- a/arch/x86/mm/pageattr.c
From: Tom Lendacky <thomas.lenda...@amd.com>
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 <thomas.lenda...@amd.com>
Signed-off-by: Brijesh Singh <brijes
7_HWCR). Only show the SEV feature
as available if reported by CPUID and enabled by BIOS.
Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com>
Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 2 +
From: Tom Lendacky <thomas.lenda...@amd.com>
When SEV is active the initrd/initramfs will already have already been
placed in memory encyrpted so do not try to encrypt it.
Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com>
Signed-off-by: Brijesh Singh <brijesh.si...@amd.com
From: Tom Lendacky <thomas.lenda...@amd.com>
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.
Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com>
Signed-off-by: B
Update amd-memory-encryption document describing the AMD Secure Encrypted
Virtualization (SEV) feature.
Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
---
Documentation/x86/amd-memory-encryption.txt | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
* update early_set_memory_* to use kernel_physical_mapping_init()
to split larger page into smaller (recommended by Boris)
* changes to address v2 feedback
Brijesh Singh (4):
Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV)
descrption
x86: Add support for changing memory
On 04/07/2017 06:33 AM, Borislav Petkov wrote:
On Thu, Apr 06, 2017 at 01:37:41PM -0500, Brijesh Singh wrote:
I did thought about prot idea but ran into another corner case which may require
us changing the signature of phys_pud_init and phys_pmd_init. The paddr_start
and paddr_end args
On 04/06/2017 12:25 PM, Borislav Petkov wrote:
Hi Brijesh,
On Thu, Apr 06, 2017 at 09:05:03AM -0500, Brijesh Singh wrote:
I looked into arch/x86/mm/init_{32,64}.c and as you pointed the file contains
routines to do basic page splitting. I think it sufficient for our usage.
Good :)
I
Hi Boris,
On 03/17/2017 05:17 AM, Borislav Petkov wrote:
On Thu, Mar 16, 2017 at 11:25:36PM +0100, Paolo Bonzini wrote:
The kvmclock memory is initially zero so there is no need for the
hypervisor to allocate anything; the point of these patches is just to
access the data in a natural way from
Hi Boris,
On 03/29/2017 10:14 AM, Borislav Petkov wrote:
On Thu, Mar 02, 2017 at 10:16:05AM -0500, Brijesh Singh wrote:
From: Tom Lendacky <thomas.lenda...@amd.com>
When a guest causes a NPF which requires emulation, KVM sometimes walks
the guest page tables to translate the GVA to
Hi Boris,
On 03/24/2017 12:12 PM, Borislav Petkov wrote:
}
+static inline int __init early_set_memory_decrypted(void *addr,
+ unsigned long size)
+{
+ return 1;
return 1 when !CONFIG_AMD_MEM_ENCRYPT ?
The non-early
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
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
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
Hi Boris,
On 03/10/2017 05:06 AM, Borislav Petkov wrote:
On Thu, Mar 02, 2017 at 10:15:15AM -0500, Brijesh Singh wrote:
If kernel_maps_pages_in_pgd is called early in boot process to change the
kernel_map_pages_in_pgd()
memory attributes then it fails to allocate memory when spliting large
Hi Boris and Paolo,
On 03/09/2017 10:29 AM, Borislav Petkov wrote:
On Thu, Mar 09, 2017 at 05:13:33PM +0100, Paolo Bonzini wrote:
This is not how you check if running under a hypervisor; you should
check the HYPERVISOR bit, i.e. bit 31 of cpuid(1).ecx. This in turn
tells you if leaf
On 03/04/2017 04:11 AM, Borislav Petkov wrote:
> On Fri, Mar 03, 2017 at 03:01:23PM -0600, Brijesh Singh wrote:
>
> This looks like a wraparound...
>
> $ test-apply.sh /tmp/brijesh.singh.delta
> checking file Documentation/admin-guide/kernel-parameters.txt
> Hunk #1 succeed
Hi Bjorn,
On 03/03/2017 02:33 PM, Bjorn Helgaas wrote:
On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote:
This RFC series provides support for AMD's new Secure Encrypted Virtualization
(SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 [1].
What kernel
Hi Boris,
On 03/03/2017 10:59 AM, Borislav Petkov wrote:
On Thu, Mar 02, 2017 at 10:12:09AM -0500, Brijesh Singh wrote:
From: Tom Lendacky <thomas.lenda...@amd.com>
Update the CPU features to include identifying and reporting on the
Secure Encrypted Virtualization (SEV) feature
hypervisor and guest can access the data.
Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
---
arch/x86/kernel/kvmclock.c | 65 ++--
1 file changed, 56 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmc
49 matches
Mail list logo
