linux-kernel - Re: [PATCH] selftests: KVM: avoid failures due to reserved HyperTransport region

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 9 Aug 2021 12:23:21 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Joao Martins <joao.m.martins@...cle.com>,
        Maxim Levitsky <mlevitsk@...hat.com>
Cc:     stable@...r.kernel.org, David Matlack <dmatlack@...gle.com>,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH] selftests: KVM: avoid failures due to reserved
 HyperTransport region

On 09/08/21 12:00, Joao Martins wrote:
> [0]https://developer.amd.com/wp-content/resources/56323-PUB_0.78.pdf
> 
> 1286 Spurious #GP May Occur When Hypervisor Running on
> Another Hypervisor
> 
> Description
> 
> The processor may incorrectly generate a #GP fault if a hypervisor running on a hypervisor
> attempts to access the following secure memory areas:
> 
> • The reserved memory address region starting at FFFD_0000_0000h and extending up to
> FFFF_FFFF_FFFFh.
> • ASEG and TSEG memory regions for SMM (System Management Mode)
> • MMIO APIC Space

This errata took a few months to debug so we're quite familiar with it 
:) but I only knew about the ASEG/TSEG/APIC cases.

So this HyperTransport region is not related to this issue, but the 
errata does point out that FFFD_0000_0000h and upwards is special in guests.

The Xen folks also had to deal with it only a couple months ago 
(https://yhbt.net/lore/all/1eb16baa-6b1b-3b18-c712-4459bd83e1aa@citrix.com/):

   From "Open-Source Register Reference for AMD Family 17h Processors 
(PUB)":
   https://developer.amd.com/wp-content/resources/56255_3_03.PDF

   "The processor defines a reserved memory address region starting at
   FFFD_0000_0000h and extending up to FFFF_FFFF_FFFFh."

   It's still doesn't say that it's at the top of physical address space
   although I understand that's how it's now implemented. The official
   document doesn't confirm it will move along with physical address space
   extension.

   [...]

   1) On parts with <40 bits, its fully hidden from software
   2) Before Fam17h, it was always 12G just below 1T, even if there was
   more RAM above this location
   3) On Fam17h and later, it is variable based on SME, and is either
   just below 2^48 (no encryption) or 2^43 (encryption)

> It's
> interesting that fn8000_000A EDX[28] is part of the reserved bits from that CPUID leaf.

It's only been defined after AMD deemed that the errata was not fixable 
in current generation processors); it's X86_FEATURE_SVME_ADDR_CHK now.

I'll update the patch based on the findings from the Xen team.

Paolo