On 03/05/19 10:40, Kai Huang wrote:
> 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.
>
> Reviewed-by: Sean Christopherson <sean.j.christopherson@xxxxxxxxx>
> Signed-off-by: Kai Huang <kai.huang@xxxxxxxxxxxxxxx>
> ---
>
> 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(-)
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index b0899f175db9..1b2380e0060f 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -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);
> }
>
Queued, thanks.
Paolo
