linux-kernel - Re: [PATCH 09/16] KVM: x86/mmu: Move private vs. shared check above slot validity checks

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: <a8dbea9d-cca7-4720-9193-6dbeaa62bb67@intel.com>
Date: Wed, 6 Mar 2024 14:22:17 +1300
From: "Huang, Kai" <kai.huang@...el.com>
To: Sean Christopherson <seanjc@...gle.com>
CC: Paolo Bonzini <pbonzini@...hat.com>, <kvm@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, Yan Zhao <yan.y.zhao@...el.com>, "Isaku
 Yamahata" <isaku.yamahata@...el.com>, Michael Roth <michael.roth@....com>, Yu
 Zhang <yu.c.zhang@...ux.intel.com>, Chao Peng <chao.p.peng@...ux.intel.com>,
	Fuad Tabba <tabba@...gle.com>, David Matlack <dmatlack@...gle.com>
Subject: Re: [PATCH 09/16] KVM: x86/mmu: Move private vs. shared check above
 slot validity checks



On 6/03/2024 1:38 pm, Sean Christopherson wrote:
> On Wed, Mar 06, 2024, Kai Huang wrote:
>>
>>
>> On 28/02/2024 3:41 pm, Sean Christopherson wrote:
>>> Prioritize private vs. shared gfn attribute checks above slot validity
>>> checks to ensure a consistent userspace ABI.  E.g. as is, KVM will exit to
>>> userspace if there is no memslot, but emulate accesses to the APIC access
>>> page even if the attributes mismatch.
>>
>> IMHO, it would be helpful to explicitly say that, in the later case (emulate
>> APIC access page) we still want to report MEMORY_FAULT error first (so that
>> userspace can have chance to fixup, IIUC) instead of emulating directly,
>> which will unlikely work.
> 
> Hmm, it's not so much that emulating directly won't work, it's that KVM would be
> violating its ABI.  Emulating APIC accesses after userspace converted the APIC
> gfn to private would still work (I think), but KVM's ABI is that emulated MMIO
> is shared-only.

But for (at least) TDX guest I recall we _CAN_ allow guest's MMIO to be 
mapped as private, right?  The guest is supposed to get a #VE anyway?

Perhaps I am missing something -- I apologize if this has already been 
discussed.

> 
> FWIW, I doubt there's a legitmate use case for converting the APIC gfn to private,
> this is purely to ensure KVM has simple, consistent rules for how private vs.
> shared access work.

Again I _think_ for TDX APIC gfn can be private?  IIUC virtualizing APIC 
is done by the TDX module, which injects #VE to guest when emulation is 
required.