From: "Reshetova, Elena" <elena.reshetova@intel.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
"Hansen, Dave" <dave.hansen@intel.com>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>,
Borislav Petkov <bp@alien8.de>,
"Lutomirski, Andy" <luto@kernel.org>,
"Kuppuswamy Sathyanarayanan"
<sathyanarayanan.kuppuswamy@linux.intel.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"x86@kernel.org" <x86@kernel.org>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 2/4] x86/tdx: Use ReportFatalError to report missing SEPT_VE_DISABLE
Date: Fri, 16 Dec 2022 15:22:15 +0000 [thread overview]
Message-ID: <DM8PR11MB5750B5E74AFEAB83D8A7170BE7E69@DM8PR11MB5750.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20221216023841.g7ebxefl2zglagek@box.shutemov.name>
>
> 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?
Yes, attestation quote has the attribute included for SEPT_VE_DISABLE.
So the remote verifier can check this, *if* it understands that it is important.
However, it is a big *IF* imo. In TDX module spec and attestation specs,
SEPT_VE_DISABLE is marked as attribute that "potentially impacts security"
vs TUD attributes like DEBUG that are classified as "your TD is not secure at all".
So, we will be relying on verifiers to understand that in Linux case it is a critical
thing vs "potentially impacting security thing".
We will document this specifically in our TDX guest kernel documentation,
but I have no guarantees on how careful people are reading it.
My preference is to do the right thing in code.
Best Regards,
Elena.
next prev parent reply other threads:[~2022-12-16 15:22 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-09 13:25 [PATCH 0/4] x86/tdx: Changes for TDX guest initialization Kirill A. Shutemov
2022-12-09 13:25 ` [PATCH 1/4] x86/tdx: Expand __tdx_hypercall() to handle more arguments Kirill A. Shutemov
2022-12-13 22:44 ` Dave Hansen
2022-12-09 13:25 ` [PATCH 2/4] x86/tdx: Use ReportFatalError to report missing SEPT_VE_DISABLE Kirill A. Shutemov
2022-12-09 15:42 ` Sathyanarayanan Kuppuswamy
2022-12-09 17:06 ` Kirill A. Shutemov
2022-12-09 20:51 ` Sathyanarayanan Kuppuswamy
2022-12-12 16:10 ` Dave Hansen
2022-12-12 16:37 ` Sathyanarayanan Kuppuswamy
2022-12-12 16:39 ` Dave Hansen
2022-12-13 23:06 ` Dave Hansen
2022-12-15 17:12 ` Kirill A. Shutemov
2022-12-15 18:18 ` Dave Hansen
2022-12-15 18:51 ` Kirill A. Shutemov
2022-12-15 21:09 ` Dave Hansen
2022-12-16 2:38 ` Kirill A. Shutemov
2022-12-16 15:22 ` Reshetova, Elena [this message]
2022-12-09 13:25 ` [PATCH 3/4] x86/tdx: Relax SEPT_VE_DISABLE check for debug TD Kirill A. Shutemov
2022-12-09 15:45 ` Sathyanarayanan Kuppuswamy
2022-12-09 17:08 ` Kirill A. Shutemov
2022-12-13 23:13 ` Dave Hansen
2022-12-15 15:40 ` Kirill A. Shutemov
2022-12-09 13:25 ` [PATCH 4/4] x86/tdx: Disable NOTIFY_ENABLES Kirill A. Shutemov
2022-12-09 15:50 ` Sathyanarayanan Kuppuswamy
2022-12-09 17:10 ` Kirill A. Shutemov
2022-12-13 23:17 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DM8PR11MB5750B5E74AFEAB83D8A7170BE7E69@DM8PR11MB5750.namprd11.prod.outlook.com \
--to=elena.reshetova@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).