Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp542855ybk; Wed, 13 May 2020 06:50:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw+zi6Yob8TmXBRecis5C01w7U0T4Yf6thU7kMt6dpdOeKyyPHMIy6mazVbmK9s5Qq+Jeo+ X-Received: by 2002:a17:906:55c4:: with SMTP id z4mr2430795ejp.332.1589377841937; Wed, 13 May 2020 06:50:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589377841; cv=none; d=google.com; s=arc-20160816; b=v+ZZGtIsG6Lnw05iLkT+rIewF0UV8JDj9R8WlYiozzR9sbZXRGeD1yR0Z5hGR0hgoO YA3AQ5aKRdD+bqLItfbTVbmecFYuclZDtDwxo31pceBPhwxpG0MG5q9E4IyN+PLXKdnD QjRX73f4D8+x2DDM4U7qNIsH6vp9PqVWgqZPb7nuOz/yD8NhJD/18PC/SUEjWOMq5hhb UGqg+ogPfENgI554XO82cRmdjD3vaOMPpGJPOT3pTdwRcRumdEey/eHT/3I/oR5Zfah6 eSLxNfdcgDmjYOcbFjmjHsF/FSvz/Uo8/y4KxkZjPfGy6RuTzkFIXijSfcgMkH/ksryR xWUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:ironport-sdr:ironport-sdr; bh=Wey9B7gGdVbe23BHbWKeebFlaoa6qx9O5P77M3TcaxA=; b=ZUHG7TAFRvZxl8sA9hIJPJBOLELHbWRXudgIWSopfXLpLxFF/gAeurRBBK9k7gLh/l hbKv+CF/fWHG+YBntW29zTB4f8wqqzIcl9qA80zoEmgA67SCWF61/dIMF5h1PuZzKfCz mPL/dO8AzbyfQGhTPwm6lPIRQM83MzXlWEuu/xibc2b+zQPOMqyaL9TVsClTw1qrWB3T +RESxnIPVQSGYf7Nj9+z0IaHl03JlZzkDYjyuHVTaeEz8xO3J5VAWLKdaSElH/i0Rlvf VT2sCnPUK7P0D42qjxMPkzWrlOlFpp2Ylut85uneZdO0e7NcagIUKOi2OMKp9kM9LO1K twcA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t9si9305899ejr.422.2020.05.13.06.50.17; Wed, 13 May 2020 06:50:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388047AbgEMNr1 (ORCPT + 99 others); Wed, 13 May 2020 09:47:27 -0400 Received: from mga18.intel.com ([134.134.136.126]:5072 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726061AbgEMNr0 (ORCPT ); Wed, 13 May 2020 09:47:26 -0400 IronPort-SDR: EXCtIL+YRbdcxYFtALXnhCa/psN9R1koqx0bCs7WtbgYTNM9MiUryoMUD1/l9QV5h/gulij/E1 IRg0FVIGfWig== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 May 2020 06:47:26 -0700 IronPort-SDR: pNqlTqHsTVGc/mVmZM9FvraTTA2PsxB4ZVZwANI3eH9UxRZx4i0sJ6GmytwqL+XeaojD3r6byj hQvKPWqhUHhQ== X-IronPort-AV: E=Sophos;i="5.73,387,1583222400"; d="scan'208";a="409691293" Received: from lhawrylk-desk.ger.corp.intel.com ([10.213.1.184]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 May 2020 06:47:21 -0700 Message-ID: <657cc4d8c6a5791ec89ef122ee84f72ff60d4089.camel@linux.intel.com> Subject: Re: [GRUB PATCH RFC 00/18] i386: Intel TXT secure launcher From: Lukasz Hawrylko To: The development of GNU GRUB Cc: linux-kernel@vger.kernel.org, trenchboot-devel@googlegroups.com, x86@kernel.org, alexander.burmashev@oracle.com, andrew.cooper3@citrix.com, ard.biesheuvel@linaro.org, dpsmith@apertussolutions.com, eric.snowberg@oracle.com, javierm@redhat.com, kanth.ghatraju@oracle.com, konrad.wilk@oracle.com, krystian.hebel@3mdeb.com, michal.zygowski@3mdeb.com, mjg59@google.com, phcoder@gmail.com, piotr.krol@3mdeb.com, pjones@redhat.com, ross.philipson@oracle.com Date: Wed, 13 May 2020 15:47:19 +0200 In-Reply-To: <20200507110634.2yvzirauq5md7d2q@tomti.i.net-space.pl> References: <20200504232132.23570-1-daniel.kiper@oracle.com> <2dad6366d2fceb0a9e36f284a8ed5a8ed86d8756.camel@linux.intel.com> <20200507110634.2yvzirauq5md7d2q@tomti.i.net-space.pl> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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