linux-kernel - Re: [PATCH] KVM: TDX: Allow userspace to return errors to guest for MAPGPA

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: <aWkb41gbjs-cPX60@google.com>
Date: Thu, 15 Jan 2026 08:54:59 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Xiaoyao Li <xiaoyao.li@...el.com>
Cc: Sagi Shahar <sagis@...gle.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>
Subject: Re: [PATCH] KVM: TDX: Allow userspace to return errors to guest for MAPGPA

On Thu, Jan 15, 2026, Xiaoyao Li wrote:
> On 1/15/2026 9:21 AM, Sagi Shahar wrote:
> > On Wed, Jan 14, 2026 at 9:57 AM Sean Christopherson <seanjc@...gle.com> wrote:
> > > On Wed, Jan 14, 2026, Xiaoyao Li wrote:
> > > > The -EINVAL will eventually be returned to userspace for the VCPU_RUN
> > > > ioctl. It certainly breaks userspace.
> > > 
> > > It _might_ break userspace.  It certainly changes KVM's ABI, but if no userspace
> > > actually utilizes the existing ABI, then userspace hasn't been broken.
> > > 
> > > And unless I'm missing something, QEMU _still_ doesn't set hypercall.ret.  E.g.
> > > see this code in __tdx_map_gpa().
> > > 
> > >          /*
> > >           * In principle this should have been -KVM_ENOSYS, but userspace (QEMU <=9.2)
> > >           * assumed that vcpu->run->hypercall.ret is never changed by KVM and thus that
> > >           * it was always zero on KVM_EXIT_HYPERCALL.  Since KVM is now overwriting
> > >           * vcpu->run->hypercall.ret, ensuring that it is zero to not break QEMU.
> > >           */
> > >          tdx->vcpu.run->hypercall.ret = 0;
> > > 
> > > AFAICT, QEMU kills the VM if anything goes wrong.
> > > 
> > > So while I initially had the exact same reaction of "this is a breaking change
> > > and needs to be opt-in", we might actually be able to get away with just making
> > > the change (assuming no other VMMs care, or are willing to change themselves).
> > 
> > Is there a better source of truth for whether QEMU uses hypercall.ret
> > or just point to this comment in the commit message.
> 
> No version of QEMU touches hypercall.ret, from the source code.
> 
> I suggest not mentioning the comment, because it only tells QEMU expects
> vcpu->run->hypercall.ret to be 0 on KVM_EXIT_HYPERCALL. What matters is QEMU
> never sets vcpu->run->hypercall.ret to a non-zero value after handling
> KVM_EXIT_HYPERCALL. I think you can just describe the fact that QEMU never
> set vcpu->run->hypercall.ret to a non-zero value in the commit message.

+1.  We can't _guarantee_ changing the behavior won't break userspace, e.g. in
theory, someone could be running a fork of QEMU in production that explicitly
sets hypercall.ret to some weird value.  Or someone could be running a VMM we
don't even know about.  I.e. there is no single source of truth, all we can do
is explain why we have high confidence that the ABI change won't break anything.