On 3/25/20 4:21 PM, Matthew Garrett wrote: > On Wed, Mar 25, 2020 at 12:43 PM Ross Philipson > <ross.philipson@xxxxxxxxxx> wrote: >> >> From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx> >> >> 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