linux-kernel - Re: [GRUB PATCH RFC 00/18] i386: Intel TXT secure launcher

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <657cc4d8c6a5791ec89ef122ee84f72ff60d4089.camel@linux.intel.com>
Date:   Wed, 13 May 2020 15:47:19 +0200
From:   Lukasz Hawrylko <lukasz.hawrylko@...ux.intel.com>
To:     The development of GNU GRUB <grub-devel@....org>
Cc:     linux-kernel@...r.kernel.org, trenchboot-devel@...glegroups.com,
        x86@...nel.org, alexander.burmashev@...cle.com,
        andrew.cooper3@...rix.com, ard.biesheuvel@...aro.org,
        dpsmith@...rtussolutions.com, eric.snowberg@...cle.com,
        javierm@...hat.com, kanth.ghatraju@...cle.com,
        konrad.wilk@...cle.com, krystian.hebel@...eb.com,
        michal.zygowski@...eb.com, mjg59@...gle.com, phcoder@...il.com,
        piotr.krol@...eb.com, pjones@...hat.com, ross.philipson@...cle.com
Subject: Re: [GRUB PATCH RFC 00/18] i386: Intel TXT secure launcher

Hi Daniel

On Thu, 2020-05-07 at 13:06 +0200, Daniel Kiper wrote:
> > There is a function that verifies if platform is TXT capable
> > -grub_txt_verify_platform(), it only checks SMX and GETSEC features.
> > Although BIOS should enforce both VMX and VT-d enabled when enabling
> > TXT, I think that adding these check here as redundancy may be a good
> 
> The TXT spec has the following pseudocode:
> 
>   //
>   // Intel TXT detection
>   // Execute on all logical processors for compatibility with
>   // multiple processor systems
>   //
>   1. CPUID(EAX=1);
>   2. IF (SMX not supported) OR (VMX not supported) {
>   3. Fail measured environment startup;
>   4. }
> 
> However, a few lines above you can find this:
> 
>   Lines 1 - 4: Before attempting to launch the measured environment, the
>   system software should check that all logical processors support VMX and
>   SMX (the check for VMX support is not necessary if the environment to be
>   launched will not use VMX).
> 
> Hence, AIUI, I am allowed to check SMX only. And I do not think that the
> bootloader should enforce VMX. If the kernel wants VMX then it should
> check the platform config. The booloader should just look for features
> which are really required to properly execute GETSEC[SENTER].

I agree with you that spec does not clearly define if VMX is required or
not. In theory you can use TXT without VMX, however this is highly
impractical because in that configuration it is impossible to use STM to
protect MLE from SMI handler as STM feature requires VMX.

All real-life MLE implementations should use STM to be compliant with
TXT idea that MLE does not have a security dependency on the pre-
existing software environment. You can find more information about STM
here: 

https://software.intel.com/content/dam/develop/external/us/en/documents/stm-user-guide-001-819978.pdf

Anyway, I have asked TXT spec owner to clarify VMX situation in next
document revision.

> 
> PS By the way, I found an issue in TXT spec. TXT.VER.FSBIF refers to
>    TXT.VER.EMIF which does not exist in spec. I suppose that it is
>    remnant from previous TXT spec versions. It seems to me that it
>    should be changed to TXT.VER.QPIIF. TXT.VER.QPIIF descriptions
>    properly, IMO, refers back to TXT.VER.FSBIF.

Yes, this is remnant from old document versions, thank you for finding
that issue. Here are changes that will go to next revision:

 * register 0x100 (TXT.VER.FSBIF) does not exist for many years and will
   be removed from TXT spec
 * register 0x200 is called TXT.VER.EMIF and indicates if chipset is
   debug of production fused

Thanks,
Lukasz