kvm: x86: Fix L1TF mitigation for shadow MMU
PATCH 1/1 kvm: x86: Fix L1TF mitigation for shadow MMU
Currently KVM sets 5 most significant bits of physical address bits reported by CPUID (boot_cpu_data.x86_phys_bits) for nonpresent or reserved bits SPTE to mitigate L1TF attack from guest when using shadow MMU. However for some particular Intel CPUs the physical address bits of internal cache is greater than physical address bits reported by CPUID.
Use the kernel's existing boot_cpu_data.x86_cache_bits to determine the five most significant bits. Doing so improves KVM's L1TF mitigation in the unlikely scenario that system RAM overlaps the high order bits of the "real" physical address space as reported by CPUID. This aligns with the kernel's warnings regarding L1TF mitigation, e.g. in the above scenario the kernel won't warn the user about lack of L1TF mitigation if x86_cache_bits is greater than x86_phys_bits.
Also initialize shadow_nonpresent_or_rsvd_mask explicitly to make it consistent with other 'shadow_{xxx}_mask', and opportunistically add a WARN once if KVM's L1TF mitigation cannot be applied on a system that is marked as being susceptible to L1TF.
---
This patch was splitted from old patch I sent out around 2 weeks ago:
kvm: x86: Fix several SPTE mask calculation errors caused by MKTME
After reviewing with Sean Christopherson it's better to split this out, since the logic in this patch is independent. And maybe this patch should also be into stable.
--- arch/x86/kvm/mmu.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)
arch/x86/kvm/mmu.c +13 -5
@@ -511,16 +511,24 @@ static void kvm_mmu_reset_all_pte_masks(void)* If the CPU has 46 or less physical address bits, then set an * appropriate mask to guard against L1TF attacks. Otherwise, it is * assumed that the CPU is not vulnerable to L1TF. +* +* Some Intel CPUs address the L1 cache using more PA bits than are +* reported by CPUID. Use the PA width of the L1 cache when possible +* to achieve more effective mitigation, e.g. if system RAM overlaps +* the most significant bits of legal physical address space. */ - low_phys_bits = boot_cpu_data.x86_phys_bits; -if (boot_cpu_data.x86_phys_bits < + shadow_nonpresent_or_rsvd_mask =0 ; + low_phys_bits = boot_cpu_data.x86_cache_bits; +if (boot_cpu_data.x86_cache_bits <52 - shadow_nonpresent_or_rsvd_mask_len) { shadow_nonpresent_or_rsvd_mask = -rsvd_bits (boot_cpu_data.x86_phys_bits - +rsvd_bits (boot_cpu_data.x86_cache_bits - shadow_nonpresent_or_rsvd_mask_len, - boot_cpu_data.x86_phys_bits -1 ); + boot_cpu_data.x86_cache_bits -1 ); low_phys_bits -= shadow_nonpresent_or_rsvd_mask_len; - } + }else +WARN_ON_ONCE (boot_cpu_has_bug (X86_BUG_L1TF )); + shadow_nonpresent_or_rsvd_lower_gfn_mask =GENMASK_ULL (low_phys_bits -1 ,PAGE_SHIFT ); }
Signature · 1 line
2.13.6
Hi Paolo/Radim,
Would you take a look?
Thanks,
-Kai
Quoted 82 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Kai Huang
Sent: Friday, May 3, 2019 8:40 PM
To: [email protected]; [email protected]; [email protected]
Cc: Christopherson, Sean J <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Huang, Kai <[email protected]>; Kai Huang <[email protected]>
Subject: [PATCH] kvm: x86: Fix L1TF mitigation for shadow MMUCurrently KVM sets 5 most significant bits of physical address bits reported by CPUID (boot_cpu_data.x86_phys_bits) for nonpresent or reserved bits SPTE to mitigate L1TF attack from guest when using shadow MMU. However for some particular Intel CPUs the physical address bits of internal cache is greater than physical address bits reported by CPUID.
Use the kernel's existing boot_cpu_data.x86_cache_bits to determine the five most significant bits. Doing so improves KVM's L1TF mitigation in the unlikely scenario that system RAM overlaps the high order bits of the "real" physical address space as reported by CPUID. This aligns with the kernel's warnings regarding L1TF mitigation, e.g. in the above scenario the kernel won't warn the user about lack of L1TF mitigation if
x86_cache_bitsis greater thanx86_phys_bits.Also initialize
shadow_nonpresent_or_rsvd_maskexplicitly to make it consistent with other 'shadow_{xxx}_mask', and opportunistically add a WARN once if KVM's L1TF mitigation cannot be applied on a system that is marked as being susceptible to L1TF.Reviewed-by Sean Christopherson <[email protected]>Signed-off-by Kai Huang <[email protected]>---
This patch was splitted from old patch I sent out around 2 weeks ago:
kvm: x86: Fix several SPTE mask calculation errors caused by MKTME
After reviewing with Sean Christopherson it's better to split this out, since the logic in this patch is independent. And maybe this patch should also be into stable.
--- arch/x86/kvm/mmu.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)arch/x86/kvm/mmu.c index renamed from arch/x86/kvm/mmu.c +0
-0
b0899f175db9..1b2380e0060f100644arch/x86/kvm/mmu.c +3
-0@@ -511,16 +511,24 @@ static void kvm_mmu_reset_all_pte_masks(void)* If the CPU has 46 or less physical address bits, then set an * appropriate mask to guard against L1TF attacks. Otherwise, it is * assumed that the CPU is not vulnerable to L1TF. +* +* Some Intel CPUs address the L1 cache using more PA bits than are +* reported by CPUID. Use the PA width of the L1 cache when possible
arch/x86/kvm/mmu.c +10
-6+* to achieve more effective mitigation, e.g. if system RAM overlaps +* the most significant bits of legal physical address space. */ - low_phys_bits = boot_cpu_data.x86_phys_bits; -if (boot_cpu_data.x86_phys_bits < + shadow_nonpresent_or_rsvd_mask =0 ; + low_phys_bits = boot_cpu_data.x86_cache_bits; +if (boot_cpu_data.x86_cache_bits <52 - shadow_nonpresent_or_rsvd_mask_len) { shadow_nonpresent_or_rsvd_mask = -rsvd_bits (boot_cpu_data.x86_phys_bits - +rsvd_bits (boot_cpu_data.x86_cache_bits - shadow_nonpresent_or_rsvd_mask_len, - boot_cpu_data.x86_phys_bits -1 ); + boot_cpu_data.x86_cache_bits -1 ); low_phys_bits -= shadow_nonpresent_or_rsvd_mask_len; - } + }else +WARN_ON_ONCE (boot_cpu_has_bug (X86_BUG_L1TF )); + shadow_nonpresent_or_rsvd_lower_gfn_mask =GENMASK_ULL (low_phys_bits -1 ,PAGE_SHIFT ); } --2.13.6
Quoted 61 lines · Kai Huang
Currently KVM sets 5 most significant bits of physical address bits reported by CPUID (boot_cpu_data.x86_phys_bits) for nonpresent or reserved bits SPTE to mitigate L1TF attack from guest when using shadow MMU. However for some particular Intel CPUs the physical address bits of internal cache is greater than physical address bits reported by CPUID.
Use the kernel's existing boot_cpu_data.x86_cache_bits to determine the five most significant bits. Doing so improves KVM's L1TF mitigation in the unlikely scenario that system RAM overlaps the high order bits of the "real" physical address space as reported by CPUID. This aligns with the kernel's warnings regarding L1TF mitigation, e.g. in the above scenario the kernel won't warn the user about lack of L1TF mitigation if
x86_cache_bitsis greater thanx86_phys_bits.Also initialize
shadow_nonpresent_or_rsvd_maskexplicitly to make it consistent with other 'shadow_{xxx}_mask', and opportunistically add a WARN once if KVM's L1TF mitigation cannot be applied on a system that is marked as being susceptible to L1TF.Reviewed-by Sean Christopherson <[email protected]>Signed-off-by Kai Huang <[email protected]>---
This patch was splitted from old patch I sent out around 2 weeks ago:
kvm: x86: Fix several SPTE mask calculation errors caused by MKTME
After reviewing with Sean Christopherson it's better to split this out, since the logic in this patch is independent. And maybe this patch should also be into stable.
--- arch/x86/kvm/mmu.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)arch/x86/kvm/mmu.c +9
-3@@ -511,16 +511,24 @@ static void kvm_mmu_reset_all_pte_masks(void)* If the CPU has 46 or less physical address bits, then set an * appropriate mask to guard against L1TF attacks. Otherwise, it is * assumed that the CPU is not vulnerable to L1TF. +* +* Some Intel CPUs address the L1 cache using more PA bits than are +* reported by CPUID. Use the PA width of the L1 cache when possible +* to achieve more effective mitigation, e.g. if system RAM overlaps +* the most significant bits of legal physical address space. */ - low_phys_bits = boot_cpu_data.x86_phys_bits; -if (boot_cpu_data.x86_phys_bits < + shadow_nonpresent_or_rsvd_mask =0 ; + low_phys_bits = boot_cpu_data.x86_cache_bits; +if (boot_cpu_data.x86_cache_bits <52 - shadow_nonpresent_or_rsvd_mask_len) { shadow_nonpresent_or_rsvd_mask = - rsvd_bits(boot_cpu_data.x86_phys_bits - + rsvd_bits(boot_cpu_data.x86_cache_bits - shadow_nonpresent_or_rsvd_mask_len,
arch/x86/kvm/mmu.c static void kvm_mmu_reset_all_pte_masks(void) · line 534
Quoted 10 lines
arch/x86/kvm/mmu.c +4
-2- boot_cpu_data.x86_phys_bits - 1); + boot_cpu_data.x86_cache_bits - 1); low_phys_bits -= shadow_nonpresent_or_rsvd_mask_len; - } + }else +WARN_ON_ONCE (boot_cpu_has_bug (X86_BUG_L1TF )); + shadow_nonpresent_or_rsvd_lower_gfn_mask =GENMASK_ULL (low_phys_bits -1 ,PAGE_SHIFT ); }
Queued, thanks.
Paolo
Quoted 66 lines · Paolo Bonzini
Quoted 65 lines · Kai Huang
Currently KVM sets 5 most significant bits of physical address bits reported by CPUID (boot_cpu_data.x86_phys_bits) for nonpresent or reserved bits SPTE to mitigate L1TF attack from guest when using shadow MMU. However for some particular Intel CPUs the physical address bits of internal cache is greater than physical address bits reported by CPUID.
Use the kernel's existing boot_cpu_data.x86_cache_bits to determine the five most significant bits. Doing so improves KVM's L1TF mitigation in the unlikely scenario that system RAM overlaps the high order bits of the "real" physical address space as reported by CPUID. This aligns with the kernel's warnings regarding L1TF mitigation, e.g. in the above scenario the kernel won't warn the user about lack of L1TF mitigation if
x86_cache_bitsis greater thanx86_phys_bits.Also initialize
shadow_nonpresent_or_rsvd_maskexplicitly to make it consistent with other 'shadow_{xxx}_mask', and opportunistically add a WARN once if KVM's L1TF mitigation cannot be applied on a system that is marked as being susceptible to L1TF.Reviewed-by Sean Christopherson <[email protected]>Signed-off-by Kai Huang <[email protected]>---
This patch was splitted from old patch I sent out around 2 weeks ago:
kvm: x86: Fix several SPTE mask calculation errors caused by MKTME
After reviewing with Sean Christopherson it's better to split this out, since the logic in this patch is independent. And maybe this patch should also be into stable.
--- arch/x86/kvm/mmu.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)arch/x86/kvm/mmu.c +11
-5@@ -511,16 +511,24 @@ static void kvm_mmu_reset_all_pte_masks(void)* If the CPU has 46 or less physical address bits, then set an * appropriate mask to guard against L1TF attacks. Otherwise, it is * assumed that the CPU is not vulnerable to L1TF. +* +* Some Intel CPUs address the L1 cache using more PA bits than are +* reported by CPUID. Use the PA width of the L1 cache when possible +* to achieve more effective mitigation, e.g. if system RAM overlaps +* the most significant bits of legal physical address space. */ - low_phys_bits = boot_cpu_data.x86_phys_bits; -if (boot_cpu_data.x86_phys_bits < + shadow_nonpresent_or_rsvd_mask =0 ; + low_phys_bits = boot_cpu_data.x86_cache_bits; +if (boot_cpu_data.x86_cache_bits <52 - shadow_nonpresent_or_rsvd_mask_len) { shadow_nonpresent_or_rsvd_mask = -rsvd_bits (boot_cpu_data.x86_phys_bits - +rsvd_bits (boot_cpu_data.x86_cache_bits - shadow_nonpresent_or_rsvd_mask_len, - boot_cpu_data.x86_phys_bits -1 ); + boot_cpu_data.x86_cache_bits -1 ); low_phys_bits -= shadow_nonpresent_or_rsvd_mask_len; - } + }else
Quoted 8 lines
arch/x86/kvm/mmu.c static void kvm_mmu_reset_all_pte_masks(void) · line 534
Quoted 6 lines
arch/x86/kvm/mmu.c +2
-0+WARN_ON_ONCE (boot_cpu_has_bug (X86_BUG_L1TF )); + shadow_nonpresent_or_rsvd_lower_gfn_mask =GENMASK_ULL (low_phys_bits -1 ,PAGE_SHIFT ); }Queued, thanks.
Hi Paolo,
Thanks for taking the patch. I am not quite sure but maybe this patch should also go into stable?
Sean, do you have comments?
Thanks,
-Kai
Quoted 2 lines
Paolo