On 09/22/2016 09:35 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 07:25:25PM -0400, 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 area
On 09/22/2016 09:45 AM, Paolo Bonzini wrote:
>
>
> On 22/09/2016 16:35, Borislav Petkov wrote:
@@ -230,6 +230,10 @@ int __init efi_setup_page_tables(unsigned long
pa_memmap, unsigned num_pages)
efi_scratch.efi_pgt = (pgd_t *)__sme_pa(efi_pgd);
pgd = efi_pgd;
On 09/22/2016 09:59 AM, Borislav Petkov wrote:
> On Thu, Sep 22, 2016 at 04:45:51PM +0200, Paolo Bonzini wrote:
>> The main difference between the SME and SEV encryption, from the point
>> of view of the kernel, is that real-mode always writes unencrypted in
>> SME and always writes encrypted in SE
On 09/22/2016 12:07 PM, Borislav Petkov wrote:
> On Thu, Sep 22, 2016 at 05:05:54PM +0200, Paolo Bonzini wrote:
>> Which paragraph?
>
> "Linux relies on BIOS to set this bit if BIOS has determined that the
> reduction in the physical address space as a result of enabling memory
> encryption..."
>
On 09/22/2016 02:11 PM, Borislav Petkov wrote:
> On Thu, Sep 22, 2016 at 02:04:27PM -0500, Tom Lendacky wrote:
>> That's not what I mean here. If the BIOS sets the SMEE bit in the
>> SYS_CFG msr then, even if the encryption bit is never used, there is
>> still a red
On 09/02/2016 03:50 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:35:39PM -0500, Tom Lendacky wrote:
>> This patch adds a Documenation entry to decribe the AMD Secure Memory
>> Encryption (SME) feature.
>>
>> Signed-off-by: Tom Lendacky
>> ---
On 09/02/2016 06:03 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:35:59PM -0500, Tom Lendacky wrote:
>> Provide the Kconfig support to build the SME support in the kernel.
>>
>> Signed-off-by: Tom Lendacky
>> ---
>> arch/x86/Kconfig |9 +
On 09/02/2016 01:14 PM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote:
>> Adding general kernel support for memory encryption includes:
>> - Modify and create some page table macros to include the Secure Memory
>> Encryption (SME) m
On 09/05/2016 10:22 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote:
>> Adding general kernel support for memory encryption includes:
>> - Modify and create some page table macros to include the Secure Memory
>> Encryption (SME) m
On 09/05/2016 03:48 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote:
>> Adding general kernel support for memory encryption includes:
>> - Modify and create some page table macros to include the Secure Memory
>> Encryption (SME) m
On 09/02/2016 09:09 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:36:22PM -0500, Tom Lendacky wrote:
>> Update the cpu features to include identifying and reporting on the
>> Secure Memory Encryption feature.
>>
>> Signed-off-by: Tom Lendacky
>> ---
>
On 09/06/2016 04:31 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote:
>> Adding general kernel support for memory encryption includes:
>> - Modify and create some page table macros to include the Secure Memory
>> Encryption (SME) m
On 09/07/2016 10:55 AM, Borislav Petkov wrote:
> On Wed, Sep 07, 2016 at 09:30:54AM -0500, Tom Lendacky wrote:
>> _PAGE_ENC is #defined as sme_me_mask and sme_me_mask has already been
>> set (or not set) at this point - so it will be the mask if SME is
>> active or 0
On 09/12/2016 05:58 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:38:07PM -0500, Tom Lendacky wrote:
>> Since DMA addresses will effectively look like 48-bit addresses when the
>> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the
>> device pe
On 09/12/2016 06:45 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:38:20PM -0500, Tom Lendacky wrote:
>> Add support to the AMD IOMMU driver to set the memory encryption mask if
>> memory encryption is enabled.
>>
>> Signed-off-by: Tom Lendacky
>
On 09/12/2016 07:17 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:38:29PM -0500, Tom Lendacky wrote:
>> Add support to check if memory encryption is active in the kernel and that
>> it has been enabled on the AP. If memory encryption is active in the kernel
>> but ha
On 09/12/2016 09:35 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:38:49PM -0500, Tom Lendacky wrote:
>> Update the KVM support to include the memory encryption mask when creating
>> and using nested page tables.
>>
>> Signed-off-by: Tom Lendacky
>
On 09/12/2016 11:33 AM, Borislav Petkov wrote:
> On Mon, Sep 12, 2016 at 10:05:36AM -0500, Tom Lendacky wrote:
>> I can look into that. The reason I put this here is this is all the
>> early page fault support that is very specific to this file. I modified
>> an existing st
On 09/12/2016 11:43 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:38:29PM -0500, Tom Lendacky wrote:
>> Add support to check if memory encryption is active in the kernel and that
>> it has been enabled on the AP. If memory encryption is active in the kernel
>
&g
On 09/12/2016 11:55 AM, Andy Lutomirski wrote:
> On Aug 22, 2016 6:53 PM, "Tom Lendacky" wrote:
>>
>> BOOT data (such as EFI related data) is not encyrpted when the system is
>> booted and needs to be accessed as non-encrypted. Add support to the
>> early
On 09/12/2016 12:08 PM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:39:08PM -0500, Tom Lendacky wrote:
>> This patch adds the support to check if SME has been enabled and if the
>> mem_encrypt=on command line option is set. If both of these conditions
>> are true, the
On 09/12/2016 11:59 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:38:59PM -0500, Tom Lendacky wrote:
>> Since the setup data is in memory in the clear, it must be accessed as
>> un-encrypted. Always use ioremap (similar to sysfs setup data support)
>> to map the d
On 09/14/2016 09:41 AM, Borislav Petkov wrote:
> On Wed, Sep 14, 2016 at 08:45:44AM -0500, Tom Lendacky wrote:
>> Currently, mem_encrypt.h only lives in the arch/x86 directory so it
>> wouldn't be able to be included here without breaking other archs.
>
> I'm wond
On 09/15/2016 04:57 AM, Matt Fleming wrote:
> On Wed, 14 Sep, at 09:20:44AM, Tom Lendacky wrote:
>> On 09/12/2016 11:55 AM, Andy Lutomirski wrote:
>>> On Aug 22, 2016 6:53 PM, "Tom Lendacky" wrote:
>>>>
>>>> BOOT data (such as EFI related data)
On 09/14/2016 09:51 AM, Borislav Petkov wrote:
> On Wed, Sep 14, 2016 at 09:29:41AM -0500, Tom Lendacky wrote:
>> This is still required because just using the __va() would still cause
>> the mapping created to have the encryption bit set. The ioremap call
>> will result in t
On 08/30/2016 09:57 AM, Andy Lutomirski wrote:
> On Aug 30, 2016 6:34 AM, "Tom Lendacky" wrote:
>>
>> On 08/25/2016 08:04 AM, Thomas Gleixner wrote:
>>> On Mon, 22 Aug 2016, Tom Lendacky wrote:
>>>
>>>> Provide support for Secure Memory
erface for SEV guests.
>>
>> Signed-off-by: Tom Lendacky
>> Signed-off-by: Brijesh Singh
>
> This driver doesn't seem to hook into the Crypto API at all, is
> there any reason why it should be in drivers/crypto?
Yes, this needs to be cleaned up. The PSP and the CC
On 7/27/2017 8:31 AM, Borislav Petkov wrote:
On Mon, Jul 24, 2017 at 02:07:46PM -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
On 7/27/2017 9:58 AM, Borislav Petkov wrote:
On Mon, Jul 24, 2017 at 02:07:47PM -0500, Brijesh Singh wrote:
From: Tom Lendacky
The current code checks only for sme_active() when determining whether
to perform the encryption attribute change. Include sev_active() in this
check so that memory
On 7/28/2017 3:47 AM, David Laight wrote:
From: Borislav Petkov
Sent: 27 July 2017 15:59
On Mon, Jul 24, 2017 at 02:07:47PM -0500, Brijesh Singh wrote:
From: Tom Lendacky
The current code checks only for sme_active() when determining whether
to perform the encryption attribute change
On 7/28/2017 5:31 AM, Borislav Petkov wrote:
On Mon, Jul 24, 2017 at 02:07:48PM -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
On 7/28/2017 10:23 AM, Borislav Petkov wrote:
On Mon, Jul 24, 2017 at 02:07:49PM -0500, Brijesh Singh wrote:
From: Tom Lendacky
The walk_iomem_res_desc(), walk_system_ram_res() and walk_system_ram_range()
functions each have much of the same code. Create a new function that
consolidates the
On 8/17/2017 1:55 PM, Tom Lendacky wrote:
On 7/28/2017 10:23 AM, Borislav Petkov wrote:
On Mon, Jul 24, 2017 at 02:07:49PM -0500, Brijesh Singh wrote:
From: Tom Lendacky
The walk_iomem_res_desc(), walk_system_ram_res() and
walk_system_ram_range()
functions each have much of the same code
On 8/1/2017 11:02 PM, Borislav Petkov wrote:
On Mon, Jul 24, 2017 at 02:07:51PM -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
On 8/6/2017 10:48 PM, Borislav Petkov wrote:
On Mon, Jul 24, 2017 at 02:07:52PM -0500, Brijesh Singh wrote:
From: Tom Lendacky
DMA access to memory mapped as encrypted while SEV is active can not be
encrypted during device write or decrypted during device read.
Yeah, definitely rewrite
On 6/20/2017 2:38 AM, Borislav Petkov wrote:
On Fri, Jun 16, 2017 at 01:51:15PM -0500, Tom Lendacky wrote:
Add support to the early boot code to use Secure Memory Encryption (SME).
Since the kernel has been loaded into memory in a decrypted state, encrypt
the kernel in place and update the
On 6/20/2017 11:17 AM, Andy Lutomirski wrote:
On Fri, Jun 16, 2017 at 11:51 AM, Tom Lendacky wrote:
The cr3 register entry can contain the SME encryption mask that indicates
the PGD is encrypted. The encryption mask should not be used when
creating a virtual address from the cr3 register, so
On 6/20/2017 3:49 PM, Thomas Gleixner wrote:
On Fri, 16 Jun 2017, Tom Lendacky wrote:
+config ARCH_HAS_MEM_ENCRYPT
+ def_bool y
+ depends on X86
That one is silly. The config switch is in the x86 KConfig file, so X86 is
on. If you intended to move this to some generic place
On 6/20/2017 3:55 PM, Thomas Gleixner wrote:
On Fri, 16 Jun 2017, Tom Lendacky wrote:
Currently there is a check if the address being mapped is in the ISA
range (is_ISA_range()), and if it is then phys_to_virt() is used to
perform the mapping. When SME is active, however, this will result
in
On 6/21/2017 2:37 AM, Thomas Gleixner wrote:
On Fri, 16 Jun 2017, Tom Lendacky wrote:
Currently there is a check if the address being mapped is in the ISA
range (is_ISA_range()), and if it is then phys_to_virt() is used to
perform the mapping. When SME is active, however, this will result
in
On 6/21/2017 2:16 AM, Thomas Gleixner wrote:
On Fri, 16 Jun 2017, Tom Lendacky wrote:
diff --git a/arch/x86/include/asm/mem_encrypt.h
b/arch/x86/include/asm/mem_encrypt.h
index a105796..988b336 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -15,16
On 6/21/2017 5:50 AM, Borislav Petkov wrote:
On Fri, Jun 16, 2017 at 01:54:36PM -0500, Tom Lendacky wrote:
Add warnings to let the user know when bounce buffers are being used for
DMA when SME is active. Since the bounce buffers are not in encrypted
memory, these notifications are to allow the
On 6/21/2017 10:38 AM, Thomas Gleixner wrote:
On Wed, 21 Jun 2017, Tom Lendacky wrote:
On 6/21/2017 2:16 AM, Thomas Gleixner wrote:
Why is this an unconditional function? Isn't the mask simply 0 when the MEM
ENCRYPT support is disabled?
I made it unconditional because of the call
On 6/21/2017 11:59 AM, Borislav Petkov wrote:
On Wed, Jun 21, 2017 at 05:37:22PM +0200, Joerg Roedel wrote:
Do you mean this is like the last exception case in that document above:
"
- Pointers to data structures in coherent memory which might be modified
by I/O devices can, sometimes,
, 2017 at 04:22:12PM -0500, Tom Lendacky wrote:
Add sysfs support for SME so that user-space utilities (kdump, etc.) can
determine if SME is active.
But why do user-space tools need to know that?
I mean, when we load the kdump kernel, we do it with the first kernel,
with the kexec_load() syscall
On 5/18/2017 2:50 PM, Matt Fleming wrote:
On Mon, 15 May, at 08:35:17PM, Borislav Petkov wrote:
On Tue, Apr 18, 2017 at 04:19:21PM -0500, Tom Lendacky wrote:
+ paddr = boot_params.efi_info.efi_memmap_hi;
+ paddr <<= 32;
+
On 5/19/2017 6:27 AM, Borislav Petkov wrote:
On Tue, Apr 18, 2017 at 04:22:23PM -0500, Tom Lendacky wrote:
Add 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). If memory
On 5/30/2017 9:55 AM, Borislav Petkov wrote:
> On Tue, May 30, 2017 at 09:38:36AM -0500, Tom Lendacky wrote:
>> In this case we're running identity mapped and the "on" constant ends up
>> as kernel address (0x81...) which results in a segfault.
>
>
On 5/19/2017 6:30 AM, Borislav Petkov wrote:
On Fri, Apr 21, 2017 at 01:56:13PM -0500, Tom Lendacky wrote:
On 4/18/2017 4:22 PM, Tom Lendacky wrote:
Add support to check if SME has been enabled and if memory encryption
should be activated (checking of command line option based on the
On 5/19/2017 3:16 PM, Josh Poimboeuf wrote:
On Fri, May 19, 2017 at 01:30:05PM +0200, Borislav Petkov wrote:
it is called so early. I can get past it by adding:
CFLAGS_mem_encrypt.o := $(nostackp)
in the arch/x86/mm/Makefile, but that obviously eliminates the support
for the whole file. Would
On 5/26/2017 11:25 AM, Borislav Petkov wrote:
On Thu, May 25, 2017 at 05:24:27PM -0500, Tom Lendacky wrote:
I guess I could do that, but this will probably only end up clearing a
single PGD entry anyway since it's highly doubtful the address range
would cross a 512GB boundary.
Or yo
On 5/21/2017 2:16 AM, Borislav Petkov wrote:
On Fri, May 19, 2017 at 03:50:32PM -0500, Tom Lendacky wrote:
The "worker" function would be doing the loop through the setup data,
but since the setup data is mapped inside the loop I can't do the __init
calling the non-init function
On 5/25/2017 11:17 PM, Xunlei Pang wrote:
On 04/19/2017 at 05:21 AM, Tom Lendacky wrote:
Provide support so that kexec can be used to boot a kernel when SME is
enabled.
Support is needed to allocate pages for kexec without encryption. This
is needed in order to be able to reboot in the kernel
On 5/26/2017 11:35 AM, Borislav Petkov wrote:
On Fri, May 26, 2017 at 11:22:36AM -0500, Tom Lendacky wrote:
In addition to the same issue as efi.memmap.phys_map, efi_phys has
the __initdata attribute so it will be released/freed which will cause
problems in checks performed afterwards.
Sounds
On 10/29/2017 8:39 PM, kernel test robot wrote:
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 67bb8e999e0aeac285d22f0e53c856b9df5282c6
Author: Tom Lendacky
AuthorDate
igned-off-by: Tom Lendacky
---
arch/x86/mm/mem_encrypt.c |1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 16c5f37..53680a9 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -63,7 +63,6 @@ static void _
On 10/25/2017 12:34 PM, Dave Hansen wrote:
On 07/18/2017 03:51 AM, tip-bot for Tom Lendacky wrote:
+/*
+ * This routine does not change the underlying encryption setting of the
+ * page(s) that map this memory. It assumes that eventually the memory is
+ * meant to be accessed as either
On 11/3/2017 10:12 AM, Tomeu Vizoso wrote:
On 17 July 2017 at 23:10, Tom Lendacky wrote:
The SMP MP-table is built by UEFI and placed in memory in a decrypted
state. These tables are accessed using a mix of early_memremap(),
early_memunmap(), phys_to_virt() and virt_to_phys(). Change all
oops when attempting a read_apic_id().
Add a boolean variable that is set to true when the MP-table is found.
Use this variable for testing if the MP-table was found so that even a
value of 0 for mpf_base will result in continued parsing of the MP-table.
Reported-by: Tomeu Vizoso
Signed-off-by: To
On 11/6/2017 2:17 PM, Tom Lendacky wrote:
> When crosvm is used to boot a kernel as a VM, the SMP MP-table is found
> at physical address 0x0. This causes mpf_base to be set to 0 and a
> subsequent "if (!mpf_base)" check in default_get_smp_config() results in
> the MP-
On 11/6/2017 3:41 PM, H. Peter Anvin wrote:
On 11/06/17 12:17, Tom Lendacky wrote:
When crosvm is used to boot a kernel as a VM, the SMP MP-table is found
at physical address 0x0. This causes mpf_base to be set to 0 and a
subsequent "if (!mpf_base)" check in default_get_smp_config()
On 10/12/2015 11:53 AM, LABBE Corentin wrote:
Precalculated hash for empty message are now present in hash headers.
This patch just use them.
Signed-off-by: LABBE Corentin
Just a minor comment below.
Tested-by: Tom Lendacky
Acked-by: Tom Lendacky
---
drivers/crypto/ccp/ccp-ops.c | 40
On 10/20/2015 02:33 AM, LABBE Corentin wrote:
Precalculated hash for empty message are now present in hash headers.
This patch just use them.
Signed-off-by: LABBE Corentin
Tested-by: Tom Lendacky
Acked-by: Tom Lendacky
---
drivers/crypto/ccp/ccp-ops.c | 39
ds the section and the attribute, a patch that re-arranges
the mapping setup and then the in-place decryption and clearing of the
encryption bit for the area.
>
> Signed-off-by: Brijesh Singh
> Fixes: 368a540e0232 ("x86/kvmclock: Remove memblock dependency")
> Cc: sta...@vger
with
> C=0. The section is pmd aligned and sized to avoid the need to split the
> pages.
> Caller can use __decrypted attribute to add the variables in .data..decrypted
> section.
>
> Cc: Tom Lendacky
> Cc: Thomas Gleixner
> Cc: Borislav Petkov
> Cc: Paolo Bonzi
On 1/21/2018 1:14 PM, Andy Lutomirski wrote:
>
>
>> On Jan 20, 2018, at 11:23 AM, KarimAllah Ahmed wrote:
>>
>> From: Tim Chen
>>
>> Create macros to control Indirect Branch Speculation.
>>
>> Name them so they reflect what they are actually doing.
>> The macros are used to restrict and unrestr
On 1/23/2018 10:20 AM, Woodhouse, David wrote:
> On Tue, 2018-01-23 at 10:12 -0600, Tom Lendacky wrote:
>>
>>>> +.macro UNRESTRICT_IB_SPEC
>>>> + ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_IBRS
>>>> + PUSH_MSR_REGS
>>&g
ppd->pgtable_area += sizeof(*pte_p) * PTRS_PER_PTE;
> -
> - pmd = native_make_pmd((pteval_t)pte_p + PMD_FLAGS);
> - native_set_pmd(pmd_p, pmd);
> - }
> -
> - pte_p += pte_index(ppd->vaddr);
> - if (!native_pte_val(*pte_p))
>
On 1/24/2018 11:57 AM, David Woodhouse wrote:
> On Wed, 2018-01-24 at 18:20 +0100, Greg KH wrote:
>> On Wed, Jan 24, 2018 at 04:57:02PM +, David Woodhouse wrote:
>>>
>>> AMD exposes the PRED_CMD/SPEC_CTRL MSRs slightly differently to Intel.
>>> See http://lkml.kernel.org/r/2b3e25cc-286d-8bd0-ae
t; Cc: Rik van Riel
> Cc: Andi Kleen
> Cc: Peter Zijlstra
> Cc: Linus Torvalds
> Cc: Jiri Kosina
> Cc: Andy Lutomirski
> Cc: Dave Hansen
> Cc: Kees Cook
> Cc: Tim Chen
> Cc: Greg Kroah-Hartman
> Cc: Paul Turner
> Cc: Tom Lendacky
> Link:
> http
t; Cc: Rik van Riel
> Cc: Andi Kleen
> Cc: Peter Zijlstra
> Cc: Linus Torvalds
> Cc: Jiri Kosina
> Cc: Andy Lutomirski
> Cc: Dave Hansen
> Cc: Kees Cook
> Cc: Tim Chen
> Cc: Greg Kroah-Hartman
> Cc: Paul Turner
> Cc: Tom Lendacky
> Link:
> http
pops at the end.
Signed-off-by: Tom Lendacky
---
arch/x86/mm/mem_encrypt_boot.S | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/x86/mm/mem_encrypt_boot.S b/arch/x86/mm/mem_encrypt_boot.S
index 730e6d5..de36884 100644
--- a/arch/x86/mm
pagetable allocation area, the virtual/physical
addresses being mapped and the pagetable flags to be used.
- Consolidate PMD/PTE mapping code to reduce duplication.
Tom Lendacky (5):
x86/mm: Cleanup register saving in mem_encrypt_boot.S
x86/mm: Use a struct to reduce parameters for SME PGD
In preparation for follow-on patches, combine the PGD mapping parameters
into a struct to reduce the number of function arguments and allow for
direct updating of the next pagetable mapping area pointer.
Signed-off-by: Tom Lendacky
---
arch/x86/mm/mem_encrypt.c | 90
microcode updates work.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/mem_encrypt.h |4 +-
arch/x86/kernel/head64.c |4 +-
arch/x86/kernel/setup.c| 10 -
arch/x86/mm/mem_encrypt.c | 66
arch/x86/mm
creating PTE page tables for the start
and end portion of the address range that fall outside of the 2MB
alignment. This results in, at most, two extra pages to hold the
PTE entries for each mapping of a range.
Signed-off-by: Tom Lendacky
---
arch/x86/mm/mem_encrypt.c | 123
caller to adjust.
Signed-off-by: Tom Lendacky
---
arch/x86/mm/mem_encrypt.c | 133 ++---
1 file changed, 77 insertions(+), 56 deletions(-)
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 5a20696..35f38ca 100644
--- a/arch/x86/mm
On 1/9/2018 6:03 AM, Paolo Bonzini wrote:
> Direct access to MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD is important
> for performance. Allow load/store of MSR_IA32_SPEC_CTRL, restore guest
> IBRS on VM entry and set it to 0 on VM exit (because Linux does not use
> it yet).
>
> Signed-off-by: Paolo
On 1/10/2018 3:14 PM, Gabriel C wrote:
> On 10.01.2018 20:25, Tom Lendacky wrote:
>
> Hi Tom ,
>
>> This patch series addresses an issue when SME is active and the BSP
>> is attempting to check for and load microcode during load_ucode_bsp().
>> Since the initrd ha
On 1/10/2018 5:47 PM, David Woodhouse wrote:
> On Wed, 2018-01-10 at 22:51 +, David Woodhouse wrote:
>> In accordance with the Intel and AMD documentation, we need to overwrite
>> all entries in the RSB on exiting a guest, to prevent malicious branch
>> target predictions from affecting the hos
On 1/11/2018 3:46 PM, David Woodhouse wrote:
> Enable the use of -mindirect-branch=thunk-extern in newer GCC, and provide
> the corresponding thunks. Provide assembler macros for invoking the thunks
> in the same way that GCC does, from native and inline assembler.
>
> This adds X86_FEATURE_RETPOL
On 1/10/2018 6:14 PM, Tom Lendacky wrote:
> On 1/10/2018 5:47 PM, David Woodhouse wrote:
>> On Wed, 2018-01-10 at 22:51 +, David Woodhouse wrote:
>>> In accordance with the Intel and AMD documentation, we need to overwrite
>>> all entries in the RSB on exiting a
On 1/12/2018 4:28 AM, David Woodhouse wrote:
> On Thu, 2018-01-11 at 17:58 -0600, Tom Lendacky wrote:
>>
>>> + * These are the bare retpoline primitives for indirect jmp and call.
>>> + * Do not use these directly; they only exist to make the ALTERNATIVE
>>
On 1/11/2018 7:32 PM, Ashok Raj wrote:
> From: Paolo Bonzini
>
> Direct access to MSR_IA32_SPEC_CTRL is important
> for performance. Allow load/store of MSR_IA32_SPEC_CTRL, restore guest
> IBRS on VM entry and set restore host values on VM exit.
> it yet).
>
> TBD: need to check msr's can be pa
On 1/12/2018 6:39 AM, Woodhouse, David wrote:
> On Fri, 2018-01-12 at 13:32 +0100, Borislav Petkov wrote:
>> On Thu, Jan 11, 2018 at 05:32:19PM -0800, Ashok Raj wrote:
>>> cpuid ax=0x7, return rdx bit 26 to indicate presence of both
>>> IA32_SPEC_CTRL(MSR 0x48) and IA32_PRED_CMD(MSR 0x49)
>>
>> So
On 1/11/2018 7:32 PM, Ashok Raj wrote:
> cpuid ax=0x7, return rdx bit 26 to indicate presence of both
> IA32_SPEC_CTRL(MSR 0x48) and IA32_PRED_CMD(MSR 0x49)
>
> BIT0: Indirect Branch Prediction Barrier
>
> When this MSR is written with IBPB=1 it ensures that earlier code's behavior
> doesn't cont
On 1/12/2018 9:36 AM, Woodhouse, David wrote:
> On Fri, 2018-01-12 at 09:31 -0600, Tom Lendacky wrote:
>>
>> AMD will follow the specification that if cpuid ax=0x7, return rdx[26]
>> is set, it will indicate both MSR registers and features are supported.
>>
>> Bu
running under a
hypervisor), the generic retpoline support will be used and, so, is also
applicable to AMD. Change the use of pause to lfence.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/nospec-branch.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch
On 1/12/2018 7:53 PM, Dan Williams wrote:
> On Fri, Jan 12, 2018 at 5:07 PM, Tom Lendacky wrote:
>> The pause instruction is currently used in the retpoline and RSB filling
>> macros as a speculation trap. The use of pause was originally suggested
>> because it show
On 1/29/2018 6:10 PM, KarimAllah Ahmed wrote:
> From: Ashok Raj
>
> Add MSR passthrough for MSR_IA32_PRED_CMD and place branch predictor
> barriers on switching between VMs to avoid inter VM Spectre-v2 attacks.
>
> [peterz: rebase and changelog rewrite]
> [karahmed: - rebase
>- vmx:
ay have side effects for the rest of
> the file.
>
> Let's isolate such functions into own translation unit.
>
> Signed-off-by: Kirill A. Shutemov
Just one minor comment at the end. With that change:
Reviewed-by: Tom Lendacky
> ---
> arch/x86/mm/Makefile
On 1/30/2018 4:28 PM, Kirill A. Shutemov wrote:
> On Tue, Jan 30, 2018 at 04:26:03PM -0600, Tom Lendacky wrote:
>> On 1/24/2018 10:36 AM, Kirill A. Shutemov wrote:
>>> There are bunch of functions in mem_encrypt.c that operate on the
>>> identity mapping, which means the
age table helpers just fine.
>
> Signed-off-by: Kirill A. Shutemov
Reviewed-by: Tom Lendacky
> ---
> arch/x86/mm/mem_encrypt_identity.c | 159
> +
> 1 file changed, 72 insertions(+), 87 deletions(-)
>
> diff --git a/arch/x86/mm/me
it in more stream-lined way to add support of
> boot-time switching between paging modes.
>
> I haven't tested the patchset on hardware capable of memory encryption.
Tested-by: Tom Lendacky
>
> v3:
> - Move all page table related functions into mem_encrypt_identi
hutemov
Reviewed-by: Tom Lendacky
> ---
> arch/x86/mm/mem_encrypt_identity.c | 42
> +++---
> 1 file changed, 12 insertions(+), 30 deletions(-)
>
> diff --git a/arch/x86/mm/mem_encrypt_identity.c
> b/arch/x86/mm/mem_encrypt_identity.c
> in
On 1/30/2018 5:26 PM, Keith Packard wrote:
> When the currently in-use hw rng is being removed from the system,
> explicitly drop it before using enable_best_rng as enable_best_rng
> will not do anything if the list of avaialble RNGs is empty.
>
> Without this, the last RNG removed from the system
On 1/31/2018 1:37 PM, KarimAllah Ahmed wrote:
> From: Ashok Raj
>
> The Indirect Branch Predictor Barrier (IBPB) is an indirect branch
> control mechanism. It keeps earlier branches from influencing
> later ones.
>
> Unlike IBRS and STIBP, IBPB does not define a new mode of operation.
> It's a c
On 1/18/2018 4:09 PM, Randy Dunlap wrote:
> On 01/18/2018 02:06 PM, Christopher Díaz Riveros wrote:
>> Fixes the following sparse warning:
>>
>> init/main.c:167:12: warning:
>> symbol 'envp_init' was not declared. Should it be static?
>>
>> Signed-off-by: Christopher Díaz Riveros
>
> Does the k
On 1/15/2018 4:47 PM, Gabriel C wrote:
> On 11.01.2018 19:33, Borislav Petkov wrote:
>> On Wed, Jan 10, 2018 at 01:25:45PM -0600, Tom Lendacky wrote:
>>> This patch series addresses an issue when SME is active and the BSP
>>> is attempting to check for and load micr
On 1/19/2018 9:11 AM, Greg Kroah-Hartman wrote:
> On Fri, Jan 19, 2018 at 09:03:52AM -0600, Tom Lendacky wrote:
>> On 1/15/2018 4:47 PM, Gabriel C wrote:
>>> On 11.01.2018 19:33, Borislav Petkov wrote:
>>>> On Wed, Jan 10, 2018 at 01:25:45PM -0600, Tom Lendacky
1 - 100 of 1358 matches
Mail list logo
