linux-kernel - Re: [PATCH v4 6/6] KVM: x86: Refactor __kvm_emulate

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: <0751a7b8-f8d3-4e27-b710-0a2bd7d06f7e@intel.com>
Date: Thu, 12 Dec 2024 09:32:36 +0200
From: Adrian Hunter <adrian.hunter@...el.com>
To: Sean Christopherson <seanjc@...gle.com>,
 Paolo Bonzini <pbonzini@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
 Tom Lendacky <thomas.lendacky@....com>, Binbin Wu
 <binbin.wu@...ux.intel.com>, Isaku Yamahata <isaku.yamahata@...el.com>,
 Kai Huang <kai.huang@...el.com>, Xiaoyao Li <xiaoyao.li@...el.com>,
 Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH v4 6/6] KVM: x86: Refactor __kvm_emulate_hypercall() into
 a macro

On 10/12/24 22:03, Sean Christopherson wrote:
> On Tue, Dec 10, 2024, Paolo Bonzini wrote:
>> On 11/28/24 09:38, Adrian Hunter wrote:
>>>
>>> For TDX, there is an RFC relating to using descriptively
>>> named parameters instead of register names for tdh_vp_enter():
>>>
>>> 	https://lore.kernel.org/all/fa817f29-e3ba-4c54-8600-e28cf6ab1953@intel.com/
>>>
>>> Please do give some feedback on that approach.  Note we
>>> need both KVM and x86 maintainer approval for SEAMCALL
>>> wrappers like tdh_vp_enter().
>>>
>>> As proposed, that ends up with putting the values back into
>>> vcpu->arch.regs[] for __kvm_emulate_hypercall() which is not
>>> pretty:
>>
>> If needed we can revert this patch, it's not a big problem.
> 
> I don't care terribly about the SEAMCALL interfaces.  I have opinions on what
> would I think would be ideal, but I can live with whatever.
> 
> What I do deeply care about though is consistency within KVM, across vendors and
> VM flavors.  And that means that guest registers absolutely need to be captured in
> vcpu->arch.regs[].

In general, TDX host VMM does not know what guest register
values are.

This case, where some GPRs are passed to the host VMM via
arguments of the TDG.VP.VMCALL TDCALL, is really just a
side effect of the choice of argument passing rather than
any attempt to share guest registers with the host VMM.

It could be regarded as more consistent to never use
vcpu->arch.regs[] for confidential guests.