Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <b19600bd-d5cf-3359-60d8-1ecd9c1ff4f5@intel.com>
Date:   Thu, 15 Dec 2022 13:09:10 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.1
Subject: Re: [PATCH 2/4] x86/tdx: Use ReportFatalError to report missing
 SEPT_VE_DISABLE
Content-Language: en-US
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
References: <20221209132524.20200-1-kirill.shutemov@linux.intel.com>
 <20221209132524.20200-3-kirill.shutemov@linux.intel.com>
 <3121847d-d334-67fc-43d8-0670c08c64b6@intel.com>
 <20221215171254.3v4maexfhkdnbfk2@box.shutemov.name>
 <795d6e1d-c79c-b079-3412-69ca2f8ee874@intel.com>
 <20221215185144.tjctmkwp5vodep3u@box>
From:   Dave Hansen <dave.hansen@intel.com>
In-Reply-To: <20221215185144.tjctmkwp5vodep3u@box>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.