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: <CAAhR5DHN+MTXX8v6LMWsQzKfpRefFwNO62hH+4iKiMpaSKiYvQ@mail.gmail.com>
Date: Wed, 14 Jan 2026 19:22:19 -0600
From: Sagi Shahar <sagis@...gle.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Xiaoyao Li <xiaoyao.li@...el.com>, Paolo Bonzini <pbonzini@...hat.com>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, Kiryl Shutsemau <kas@...nel.org>, 
	Rick Edgecombe <rick.p.edgecombe@...el.com>, Thomas Gleixner <tglx@...nel.org>, 
	Borislav Petkov <bp@...en8.de>, "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org, kvm@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-coco@...ts.linux.dev, 
	Vishal Annapurve <vannapurve@...gle.com>, Michael Roth <michael.roth@....com>
Subject: Re: [PATCH] KVM: TDX: Allow userspace to return errors to guest for MAPGPA

On Wed, Jan 14, 2026 at 3:48 PM Sean Christopherson <seanjc@...gle.com> wrote:
>
> +Mike
>
> On Wed, Jan 14, 2026, Sean Christopherson wrote:
> > On Wed, Jan 14, 2026, Xiaoyao Li wrote:
> > > On 1/14/2026 8:30 AM, Sagi Shahar wrote:
> > > So it needs to be
> > >
> > >     if (vcpu->run->hypercall.ret == -EBUSY)
> > >             tdvmcall_set_return_code(vcpu, TDVMCALL_STATUS_RETRY);
> > >     else
> > >             tdvmcall_set_return_code(vcpu, TDVMCALL_STATUS_INVALID_OPERAND);
> >
> > No, because assuming everything except -EBUSY translates to
> > TDVMCALL_STATUS_INVALID_OPERAND paints KVM back into the same corner its already
> > in.  What I care most about is eliminating KVM's assumption that a non-zero
> > hypercall.ret means TDVMCALL_STATUS_INVALID_OPERAND.
> >
> > For the new ABI, I see two options:
> >
> >  1. Translate -errno as done in this patch.
> >  2. Propagate hypercall.ret directly to the TDVMCALL return code, i.e. let
> >     userspace set any return code it wants.
> >
> > #1 has the downside of needing KVM changes and new uAPI every time a new return
> > code is supported.
> >
> > #2 has the downside of preventing KVM from establishing its own ABI around the
> > return code, and making the return code vendor specific.  E.g. if KVM ever wanted
> > to do something in response to -EBUSY beyond propagating the error to the guest,
> > then we can't reasonably do that with #2.
> >
> > Whatever we do, I want to change snp_complete_psc_msr() and snp_complete_one_psc()
> > in the same patch, so that whatever ABI we establish is common to TDX and SNP.
> >
> > See also https://lore.kernel.org/all/Zn8YM-s0TRUk-6T-@google.com.
>
> Aha!  Finally.  I *knew* we had discussed this more recently.  The SNP series to
> add KVM_EXIT_SNP_REQ_CERTS uses a similar pattern.  Note its intentional use of
> positive values, because that's what userspace sees in errno.  This code should
> do the same.  Oh, and we need to choose between EAGAIN and EBUSY...
>
>         switch (READ_ONCE(vcpu->run->snp_req_certs.ret)) {
>         case 0:
>                 return snp_handle_guest_req(svm, control->exit_info_1,
>                                             control->exit_info_2);
>         case ENOSPC:
>                 vcpu->arch.regs[VCPU_REGS_RBX] = vcpu->run->snp_req_certs.npages;
>                 return snp_req_certs_err(svm, SNP_GUEST_VMM_ERR_INVALID_LEN);
>         case EAGAIN:
>                 return snp_req_certs_err(svm, SNP_GUEST_VMM_ERR_BUSY);
>         case EIO:
>                 return snp_req_certs_err(svm, SNP_GUEST_VMM_ERR_GENERIC);
>         default:
>                 break;
>         }
>

I think EAGAIN makes more sense semantically in this case. So
something like this?

-               tdvmcall_set_return_code(vcpu, TDVMCALL_STATUS_INVALID_OPERAND);
+               if (vcpu->run->hypercall.ret == EAGAIN)
+                       tdvmcall_set_return_code(vcpu, TDVMCALL_STATUS_RETRY);
+               else if (vcpu->run->hypercall.ret == EINVAL)
+                       tdvmcall_set_return_code(vcpu,
TDVMCALL_STATUS_INVALID_OPERAND);
+               else
+                       return -EINVAL;
+

>
> https://lore.kernel.org/all/20260109231732.1160759-2-michael.roth@amd.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ