Re: [PATCH 2/4] x86/tdx: Use ReportFatalError to report missing SEPT_VE_DISABLE

[Kirill A. Shutemov]

On Thu, Dec 15, 2022 at 01:09:10PM -0800, Dave Hansen wrote:
> On 12/15/22 10:51, Kirill A. Shutemov wrote:
> >>> So ReportFatalError() is no good for the task. And I don't have anything
> >>> else :/
> >> Do we *really* have to do a hard stop when SEPT_VE_DISABLE is missing?
> >>
> >> Wouldn't it be simpler to just defer the check until we can spit out a
> >> sane error message about it?
> >>
> >> Or is there too much security exposure by continuing?
> > Well, I guess we can. We always have attestation as a backstop. No
> > sensitive user data has to be exposed to the TD before it passed
> > the attestation.
> 
> OK, so let's just pretend that SEPT_VE_DISABLE=0 is a blatant root hole
> that lets the VMM compromise the TDX guest (I know it's not, but let's
> just pretend it is).
> 
> The guest starts up, the VMM compromises it after the attestation has
> run.  The now compromised guest send along its report.  But, since the
> report contains (or implies???) SEPT_VE_DISABLE=0, the guest will be
> assumed to be compromised and won't get any secrets provisioned?
> 
> That assumes that the attestation service knows that SEPT_VE_DISABLE==0
> plus Linux is bad.  Is that a good assumption?

I know that attestation quote includes all required information
(attributes and kernel hash) to make the decision and I assume that
attestation service is competent. So, yes, I think expectation Linux +
SEPT_VE_DISABLE==0 going to be rejected is reasonable.

Elena, is there anything you can elaborate on here?

> > Do you prefer to have a separate initcall just to check SEPT_VE_DISABLE?
> 
> I don't feel strongly about where the check should be as long as it can
> get a message out to the console.

I would rather keep current approach with simple tdx_panic() for early
use if it works for you.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov