linux-kernel - Re: [PATCH v1 4/5] KVM: Introduce KVM_EXIT

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: <6fc71b3c-fbc1-4fb8-9692-f85d3166a68f@linux.intel.com>
Date: Wed, 20 Nov 2024 12:03:49 +0800
From: Binbin Wu <binbin.wu@...ux.intel.com>
To: Michael Roth <michael.roth@....com>
Cc: Sean Christopherson <seanjc@...gle.com>, kvm@...r.kernel.org,
 linux-coco@...ts.linux.dev, linux-kernel@...r.kernel.org, x86@...nel.org,
 pbonzini@...hat.com, jroedel@...e.de, thomas.lendacky@....com,
 pgonda@...gle.com, ashish.kalra@....com, bp@...en8.de, pankaj.gupta@....com,
 liam.merwick@...cle.com, Rick Edgecombe <rick.p.edgecombe@...el.com>,
 Reinette Chatre <reinette.chatre@...el.com>,
 "Yamahata, Isaku" <isaku.yamahata@...el.com>,
 "Peng, Chao P" <chao.p.peng@...el.com>
Subject: Re: [PATCH v1 4/5] KVM: Introduce KVM_EXIT_COCO exit type




On 11/19/2024 9:53 PM, Michael Roth wrote:
[...]
> A few weeks back we discussed during the PUCK call on whether it makes
> sense for use a common exit type for REQ_CERTS and TDX_GET_QUOTE, and
> due to the asynchronous/polling nature of TDX_GET_QUOTE, and the
> somewhat-particular file-locking requirements that need to be built into
> the REQ_CERTS handling, we'd decided that it's probably more trouble
> than it's worth to try to merge the 2.
>
> However, I'm still hoping that KVM_EXIT_COCO might still provide some
> useful infrastructure for introducing something like
> KVM_EXIT_COCO_GET_QUOTE that implements the TDX-specific requirements
> more directly.
I am not sure it benefits much.
Since the handling codes of REQ_CERTS and  TDX_GET_QUOTE in userspace are
quite different, i.e., there will be little common code to reuse, but it
requires KVM to convert the error code from the KVM_EXIT_COCO version to
vendor specific versions.


>
> I've just submitted v2 of KVM_EXIT_COCO where the userspace-provided
> error codes are reworked to be less dependent on specific spec-defined
> values but instead relies on standard error codes that KVM can provide
> special handling for internally when needed:
>
>    https://lore.kernel.org/kvm/20241119133513.3612633-1-michael.roth@amd.com/
>
> But I suppose in your case userspace would just return "SUCCESS"/0 and
According to GHCI spec, besides "TDG.VP.VMCALL_SUCCESS", there are two more
error codes "TDG.VP.VMCALL_RETRY" and "TDG.VP.VMCALL_INVALID_OPERAND".
"TDG.VP.VMCALL_RETRY" could cover EAGAIN.
"TDG.VP.VMCALL_INVALID_OPERAND" could be used to cover the other errors
returned, i.e., EIO and ENOSPC according to your proposal in v2.

> then all the vendor-specific values are mainly in relation to the
> "Status Code" field so it likely doesn't make a huge difference as far
> as what userspace passes back to KVM.
>
> Thanks,
>
> Mike
>
[...]