linux-kernel - Re: [PATCH v19 007/130] x86/virt/tdx: Export SEAMCALL functions

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]

Date: Fri, 15 Mar 2024 12:20:30 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Rick P Edgecombe <rick.p.edgecombe@...el.com>
Cc: Dave Hansen <dave.hansen@...el.com>, Tina Zhang <tina.zhang@...el.com>, 
	Hang Yuan <hang.yuan@...el.com>, Kai Huang <kai.huang@...el.com>, 
	"x86@...nel.org" <x86@...nel.org>, Bo Chen <chen.bo@...el.com>, 
	"sagis@...gle.com" <sagis@...gle.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>, Erdem Aktas <erdemaktas@...gle.com>, 
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com" <pbonzini@...hat.com>, 
	Isaku Yamahata <isaku.yamahata@...el.com>
Subject: Re: [PATCH v19 007/130] x86/virt/tdx: Export SEAMCALL functions

On Fri, Mar 15, 2024, Rick P Edgecombe wrote:
> On Fri, 2024-03-15 at 10:46 -0700, Sean Christopherson wrote:
> > On Fri, Mar 15, 2024, Sean Christopherson wrote:
> > > So my feedback is to not worry about the exports, and instead focus on
> > > figuring out a way to make the generated code less bloated and easier to
> > > read/debug.
> > 
> > Oh, and please make it a collaborative, public effort.  I don't want to
> > hear crickets and then see v20 dropped with a completely new SEAMCALL
> > scheme.
> 
> And here we we're worrying that people might eventually grow tired of
> us adding mails to v19 and we debate every detail in public. Will do.

As a general rule, I _strongly_ prefer all review to be done on-list, in public.
Copy+pasting myself from another Intel series[*]

 : Correct, what I object to is Intel _requiring_ a Reviewed-by before posting.
 : 
 : And while I'm certainly not going to refuse patches that have been reviewed
 : internally, I _strongly_ prefer reviews be on-list so that they are public and
 : recorded.  Being able to go back and look at the history and evolution of patches
 : is valuable, and the discussion itself is often beneficial to non-participants,
 : e.g. people that are new-ish to KVM and/or aren't familiar with the feature being
 : enabled can often learn new things and avoid similar pitfalls of their own.

There are definitely situations where exceptions are warranted, e.g. if someone
is a first-time poster and/or wants a sanity check to make sure their idea isn't
completely crazy.  But even then, the internal review should only be very cursory.

In addition to the history being valuable, doing reviews in public minimizes the
probability of a developer being led astray, e.g. due to someone internally saying
do XYZ, and then upstream reviewers telling them to do something entirely different. 

As far as noise goes, look at it this way.  Every time a new TDX series is posted,
I get 130+ emails.  Y'all can do a _lot_ of public review and discussion before
you'll get anywhere near the point where it'd be noiser than spinning a new version
of the series.

[*] https://lore.kernel.org/all/Y+ZxLfCrcTQ6poYg@google.com