Re: [RFC v1 00/26] Add TDX Guest Support

[Andi Kleen]

On Sat, Apr 03, 2021 at 09:26:24AM -0700, Dave Hansen wrote:
> On 4/2/21 2:32 PM, Andi Kleen wrote:
> >> If we go this route, what are the rules and restrictions?  Do we have to
> >> say "no MMIO in #VE"?
> > 
> > All we have to say is "No MMIO in #VE before getting thd TDVEINFO arguments"
> > After that it can nest without problems.
> 
> Well, not exactly.  You still can't do things that will could cause a n
> unbounded recusive #VE.

> It doesn't seem *that* far fetched to think that someone might try to
> defer some work or dump data to the console.

I believe the main console code has reentry protection.

I'm not sure about early_printk (with keep), buf it that's the case
it probably should be fixed anyways. I can take a look at that.

Not sure why deferring something would cause another #VE?

 
> > If you nest before that the TDX will cause a triple fault.
> > 
> > The code that cannot do it is a few lines in the early handler which
> > runs with interrupts off.
> 
> >> Which brings up another related point: How do you debug TD guests?  Does
> >> earlyprintk work?
> > 
> > Today it works actually because serial ports are allowed. But I expect it to
> > be closed eventually because serial code is a lot of code to audit. 
> > But you can always disable the filtering with a command line option and
> > then it will always work for debugging.
> 
> Do we need a TDX-specific earlyprintk?  I would imagine it's pretty easy
> to implement.

Don't see a need at this point, the existing mechanisms work.

Maybe if we ever have a problem that only happen in lockdown *and* happens
early, but that's not very likely since lock down primarily changes code
behavior later.

There are also other debug mechanisms for such cases: in TDX if you configure
the TD for debug mode supports using the gdb stub on the hypervisor.

-Andi