linux-kernel - Re: [PATCH] x86/tdx: Enhance code generation for TDCALL and SEAMCALL wrappers

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: <ZuIoYUnJ9uJoSLzm@google.com>
Date: Wed, 11 Sep 2024 16:31:45 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Rick P Edgecombe <rick.p.edgecombe@...el.com>
Cc: "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>, 
	"linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>, "jpoimboe@...nel.org" <jpoimboe@...nel.org>, 
	Dave Hansen <dave.hansen@...el.com>, 
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, 
	"haiyangz@...rosoft.com" <haiyangz@...rosoft.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "mingo@...hat.com" <mingo@...hat.com>, 
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "kys@...rosoft.com" <kys@...rosoft.com>, 
	Dexuan Cui <decui@...rosoft.com>, "tglx@...utronix.de" <tglx@...utronix.de>, 
	"hpa@...or.com" <hpa@...or.com>, "peterz@...radead.org" <peterz@...radead.org>, 
	"wei.liu@...nel.org" <wei.liu@...nel.org>, "bp@...en8.de" <bp@...en8.de>, 
	"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>, "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH] x86/tdx: Enhance code generation for TDCALL and SEAMCALL wrappers

On Wed, Aug 28, 2024, Rick P Edgecombe wrote:
> On Tue, 2024-06-04 at 12:34 -0700, Sean Christopherson wrote:
> > 
> > If we're willing to suffer a few gnarly macros, I think we get a
> > satisfactory mix of standardized arguments and explicit operands, and
> > generate vastly better code.
> 
> Hi Sean,
> 
> We are kind of stuck on improving the code generation for the existing calls.
> x86 maintainers don't seem to be enthusiastic about tackling this urgently and
> there is not consensus on how to weigh source code clarity with code generation
> sanity [0]. I think we are going to table it for the time being, unless it's a
> showstopper for you.

I'll survive.

> An option is still to have a separate helper infrastructure for KVM's calls, but
> as discussed originally this duplicates code.

Ya.  Tangentially related to this topic, at some point in the not-to-distant
future, I think we need to have a discussion for how to maintain TDX (and SNP)
going forward.

Not because I want to take more ownership in KVM (I would generally prefer to do
the opposite), but because I suspect there will be more overlaps similar to this
in the future, e.g. if the guest kernel gets cornered into doing some amount
of SSE/AVX emulation for userspace MMIO.  And because I also suspect that future
additions to TDX and SNP will require modifications and tighter integration in/with
subsystems outside of KVM, while simultaneously moving further away from the areas
that KVM has historically operated in, e.g. emulation, feature enumeration, memory
management, etc.

I don't have any concrete (or even half-baked) thoughts, just flagging that we
might want to have a conversation to hash out what we think would be the best
way to operate, knowing what's on the horizon, versus winging it as we go and
hoping everything works out.