Messages in this thread |  | | Date | Fri, 16 Dec 2022 05:38:41 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCH 2/4] x86/tdx: Use ReportFatalError to report missing SEPT_VE_DISABLE |
| |
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
|  |