public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Jonathan McDowell <noodles@fb.com>
Cc: Dmitrii Okunev <xaionaro@fb.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Mark Gross <markgross@kernel.org>,
	Qiaowei Ren <qiaowei.ren@intel.com>,
	Xiaoyan Zhang <xiaoyan.zhang@intel.com>,
	Pavel Machek <pavel@denx.de>, Greg Kroah-Hartman <greg@kroah.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"platform-driver-x86@vger.kernel.org" 
	<platform-driver-x86@vger.kernel.org>
Subject: Re: [RFC PATCH] platform/x86: Add sysfs interface for Intel TXT status
Date: Wed, 9 Mar 2022 10:53:43 +0000	[thread overview]
Message-ID: <20220309105343.GA14476@srcf.ucam.org> (raw)
In-Reply-To: <YiiD3WM76L3jbMyW@noodles-fedora-PC23Y6EG.dhcp.thefacebook.com>

On Wed, Mar 09, 2022 at 10:40:03AM +0000, Jonathan McDowell wrote:

> This module provides read-only access to the Intel TXT (Trusted
> Execution Technology) status registers, allowing userspace to determine
> the status of measured boot and whether the dynamic root of trust for
> measurement (DRTM) has been fully enabled.

So there's the obvious issue that in the event that the system has been 
compromised this information is no longer trustworthy - is this expected 
to just be informative for diagnostic purposes rather than forming any 
part of security policy?

> +	  These registers provide details about the status of the platform's
> +	  measured launch and execution environment, allowing userspace to
> +	  make trust based decisions. See tboot

Mm. This makes it sound like it's expected that userspace make decisions 
based on this, which sounds like a bad plan?

> +/* Shows if TXT has been enabled */
> +static int txt_enabled_show(struct seq_file *m, void *v)
> +{
> +	/* If the BIOS has enabled TXT then the heap base will be set */

Sorry it's not that I want to say "Wait are you trusting that the BIOS 
will do the right thing here" but wait are you trusting that the BIOS 
will do the right thing here? Does setting the heap base guarantee that 
TXT was enabled (and, conversely, are there any scenarios where TXT was 
enabled and the BIOS could have cleared the heap base after a 
measurement event?)

> +/* Shows the 256 bit hash of the public key */
> +static int txt_key_show(struct seq_file *m, void *v)
> +{
> +	seq_printf(m, "%016llx%016llx%016llx%016llx\n",
> +		cpu_to_be64(*(u64 *)(txt_pub_regs + TXT_CR_PUBLIC_KEY)),
> +		cpu_to_be64(*(u64 *)(txt_pub_regs + TXT_CR_PUBLIC_KEY + 8)),
> +		cpu_to_be64(*(u64 *)(txt_pub_regs + TXT_CR_PUBLIC_KEY + 16)),
> +		cpu_to_be64(*(u64 *)(txt_pub_regs + TXT_CR_PUBLIC_KEY + 24)));

What's the expected consumer of this, and what are they expected to do 
with it?


  parent reply	other threads:[~2022-03-09 10:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-13 17:24 [PATCH v2 0/3] Intel TXT driver Qiaowei Ren
2013-05-13 17:24 ` [PATCH v2 1/3] driver: add TXT driver in kernel Qiaowei Ren
2013-05-13 17:31   ` Matthew Garrett
2013-05-14  1:49     ` Ren, Qiaowei
2013-05-13 17:24 ` [PATCH v2 2/3] driver: provide sysfs interfaces to access TXT config space Qiaowei Ren
2013-05-13 17:35   ` Matthew Garrett
2013-05-14  1:46     ` Ren, Qiaowei
2013-05-16 16:03   ` Pavel Machek
2013-05-17  8:50     ` Ren, Qiaowei
2013-05-17 18:07       ` Pavel Machek
2022-02-17 11:47     ` [discuss] Improve and merge a driver proposed in 2013: " Dmitrii Okunev
2022-02-17 12:34       ` greg
2022-02-17 12:37         ` Pavel Machek
2022-02-18 18:05           ` Jonathan McDowell
2022-02-22  9:31             ` Pavel Machek
2022-03-09 10:40               ` [RFC PATCH] platform/x86: Add sysfs interface for Intel TXT status Jonathan McDowell
2022-03-09 10:48                 ` Greg KH
2022-03-09 10:58                   ` Jonathan McDowell
2022-03-09 11:29                     ` Greg KH
2022-03-09 10:53                 ` Matthew Garrett [this message]
2022-03-09 17:55                   ` Jonathan McDowell
2022-04-12 14:23                 ` [RFC PATCH v2] platform/x86: Add securityfs interface for " Jonathan McDowell
2013-05-13 17:24 ` [PATCH v2 3/3] driver: provide sysfs interfaces to access SMX parameter Qiaowei Ren

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=20220309105343.GA14476@srcf.ucam.org \
    --to=mjg59@srcf.ucam.org \
    --cc=greg@kroah.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markgross@kernel.org \
    --cc=noodles@fb.com \
    --cc=pavel@denx.de \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=qiaowei.ren@intel.com \
    --cc=x86@kernel.org \
    --cc=xaionaro@fb.com \
    --cc=xiaoyan.zhang@intel.com \
    /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