linux-kernel - Re: [PATCH RFC] x86/kvm/lapic: always disable MMIO interface in x2APIC mode

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:   Thu, 2 Aug 2018 13:54:51 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     Jim Mattson <jmattson@...gle.com>, kvm list <kvm@...r.kernel.org>,
        Radim Krčmář <rkrcmar@...hat.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC] x86/kvm/lapic: always disable MMIO interface in
 x2APIC mode

On 30/07/2018 11:14, Vitaly Kuznetsov wrote:
> Paolo Bonzini <pbonzini@...hat.com> writes:
> 
>> On 27/07/2018 18:48, Jim Mattson wrote:
>>> On a physical machine, I would expect the default local APIC page to
>>> fall in the PCI hole, so it would be correct to sink writes and to
>>> return all ones for reads. Does qemu implement a PCI hole, and does
>>> this address fall into it?
>>
>> It does implement a PCI hole, but when using the kernel LAPIC it expects
>> that only devices write to that range; therefore that address doesn't
>> fall into the PCI hole, and instead it generates an MSIs.
> 
> Yes, and that's why I believe it's correct to never forward lapic
> reads/writes from KVM to userspace when lapic is in kernel.
> 
> "RFC" was mostly about the inconsistency with the case when APIC access
> page is in use. To be 100% correct I would suggest to somehow make it
> behave like MMIO hole in case we're in x2APIC/disabled mode too.
> 

FWIW it is possible to move the MSI memory region from system memory to
the PCI address space in QEMU, however I'm worried about backwards
compatibility.

Vitaly, perhaps you could resubmit this patch, and provide a
KVM_CAP_DISABLE_QUIRKS switch that would make apic_mmio_{read,write}
return -EOPNOTSUPP in this case?

Thanks,

Paolo