All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Kuppuswamy Sathyanarayanan
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Elena Reshetova <elena.reshetova@intel.com>,
	x86@kernel.org, linux-coco@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] x86/tdx: Use ReportFatalError to report missing SEPT_VE_DISABLE
Date: Thu, 15 Dec 2022 13:09:10 -0800	[thread overview]
Message-ID: <b19600bd-d5cf-3359-60d8-1ecd9c1ff4f5@intel.com> (raw)
In-Reply-To: <20221215185144.tjctmkwp5vodep3u@box>

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?

> 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.

  reply	other threads:[~2022-12-15 21:09 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 [this message]
2022-12-16  2:38             ` Kirill A. Shutemov
2022-12-16 15:22               ` Reshetova, Elena
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=b19600bd-d5cf-3359-60d8-1ecd9c1ff4f5@intel.com \
    --to=dave.hansen@intel.com \
    --cc=bp@alien8.de \
    --cc=elena.reshetova@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.