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] [day] [month] [year] [list]

Message-ID: <YbDjN68ALDavh1WQ@google.com>
Date:   Wed, 8 Dec 2021 16:54:15 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Joao Martins <joao.m.martins@...cle.com>,
        Maxim Levitsky <mlevitsk@...hat.com>, 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 Mon, Aug 09, 2021, Paolo Bonzini wrote:
> 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.

So, about that update... :-)