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]

Message-ID: <bab67d1c-f9b7-0a91-2d4f-9881e3f47218@oracle.com>
Date:   Mon, 9 Aug 2021 11:00:23 +0100
From:   Joao Martins <joao.m.martins@...cle.com>
To:     Paolo Bonzini <pbonzini@...hat.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 8/9/21 10:03 AM, Paolo Bonzini wrote:
> On 06/08/21 12:57, Joao Martins wrote:
>>   Base Address   Top Address   Use
>>
>>    FD_0000_0000h FD_F7FF_FFFFh Reserved interrupt address space
>>    FD_F800_0000h FD_F8FF_FFFFh Interrupt/EOI IntCtl
>>    FD_F900_0000h FD_F90F_FFFFh Legacy PIC IACK
>>    FD_F910_0000h FD_F91F_FFFFh System Management
>>    FD_F920_0000h FD_FAFF_FFFFh Reserved Page Tables
>>    FD_FB00_0000h FD_FBFF_FFFFh Address Translation
>>    FD_FC00_0000h FD_FDFF_FFFFh I/O Space
>>    FD_FE00_0000h FD_FFFF_FFFFh Configuration
>>    FE_0000_0000h FE_1FFF_FFFFh Extended Configuration/Device Messages
>>    FE_2000_0000h FF_FFFF_FFFFh Reserved
> 
> The problems we're seeing are with FFFD_0000_0000h.  How does the IOMMU 
> interpret bits 40-47 of the address?

The IOMMU supposedly makes an invalid device request iommu fault event when touching the
reserved interrupt address space. But that presumes performing DMA from/to device with
said IOVA=fdXXXXXXXX (doesn't matter if it's guest or baremetal).

Oh wait. You asked fffd******** not 00fd******** which then the spec quote I gave doesn't
document what you're aiming for. Ugh, sorry if I mislead you and Maxim. My mind eliminated
the starting 0xff when reading the address given the similarity.

But I've seen that address range somewhere. This errata might help [0]? But anyways, it
doesn't explain why how this is interpreted, just that it is 'reserved'. It doesn't look
to be HyperTransport address range either as that would be the 1010..1023G range (close to
1T) as documented by the IOMMU manual, not the 256T boundary (fffd********). It's
interesting that fn8000_000A EDX[28] is part of the reserved bits from that CPUID leaf.

[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

Potential Effect on System

Software running a hypervisor on a hypervisor may encounter an unexpected #GP fault.

Suggested Workaround

If CPUID bit fn8000_000A EDX[28] = 0b, then:
• Hypervisor software can trap #GP faults that potentially have this issue and ignore #GP
faults that were
erroneously generated.
If CPUID bit fn8000_000A EDX[28] = 1b, then the issue has been fixed and no workaround is
necessary.
Fix Planned
No fix planned