linux-kernel - Re: [RFC PATCH 10/12] x86: Secure Launch adding event log securityfs

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: <38ab048a-f2b0-9778-d9ce-c15374abde94@apertussolutions.com>
Date:   Wed, 25 Mar 2020 17:43:30 -0400
From:   "Daniel P. Smith" <dpsmith@...rtussolutions.com>
To:     Matthew Garrett <mjg59@...gle.com>,
        Ross Philipson <ross.philipson@...cle.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        linux-doc@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, trenchboot-devel@...glegroups.com
Subject: Re: [RFC PATCH 10/12] x86: Secure Launch adding event log securityfs

On 3/25/20 4:21 PM, Matthew Garrett wrote:
> On Wed, Mar 25, 2020 at 12:43 PM Ross Philipson
> <ross.philipson@...cle.com> wrote:
>>
>> From: "Daniel P. Smith" <dpsmith@...rtussolutions.com>
>>
>> The late init functionality registers securityfs nodes to allow fetching
>> of and writing events to the late launch TPM log.
> 
> Is there a reason we would want this exposed separately from the
> regular event log, rather than just appending it there?

We created a separate securityfs node as the intent is to eventually
expose additional information relating to state of the Dynamic Launch.
We only implemented the log node as it is the only node we required for
demonstrating the initial capability. By no means are we tied to this
path for the log. If maintainers would like to see the DRTM log be
colocated with the SRTM log, we can move the logic over to the tpm
driver's eventlog code.

>> +static ssize_t sl_evtlog_write(struct file *file, const char __user *buf,
>> +                               size_t datalen, loff_t *ppos)
>> +{
> 
> What's expected to be writing to this?
> 

We want to support a multitude of use cases but for an initial
demonstrator it was felt better to emulate the way people are using
Intel TXT, via tboot as an intermediate loader in the boot chain. When
using a Secure Launch for an intermediate loader implementation, the
implementer has the richness of the user-space runtime for collecting
measurements. As a result they may want(be forced) to do the hashing in
user-space and since this is a measurement that is part of the DRTM
chain it needs to get appended to that log. Thus it seemed natural to
enable the extending of the log by allowing one to write to the log's
securityfs node.

V/r,
Daniel P. Smith