Re: [Qemu-devel] [PATCH] hw/misc: Add simple measurement hardware

[Daniel P. Berrange]

On Thu, Jun 23, 2016 at 04:36:59PM -0700, Matthew Garrett wrote:
> Trusted Boot is based around having a trusted store of measurement data and a
> secure communications channel between that store and an attestation target. In
> actual hardware, that's a TPM. Since the TPM can only be accessed via the host
> system, this in turn requires that the TPM be able to perform reasonably
> complicated cryptographic functions in order to demonstrate its trusted state.
> 
> In cloud environments, qemu is inherently trusted and the hypervisor 
> infrastructure
> provides a trusted mechanism for extracting information from qemu and 
> providing it
> to another system. This means we can skip the crypto and stick with the basic
> functionality - ie, providing a trusted store of measurement data.
> 
> This driver provides a very small subset of TPM 1.2 functionality in the form 
> of a
> bank of registers that can store SHA1 measurements of boot components. 
> Performing a
> write to one of these registers will append the new 20 byte hash to the 20 
> bytes
> currently stored within the register, take a SHA1 of this 40 byte value and 
> then
> replace the existing register contents with the new value. This ensures that a
> given value can only be obtained by performing the same sequence of writes. 
> It also
> adds a monitor command to allow an external agent to extract this information 
> from
> the running system and provide it over a secure communications channel. 
> Finally, it
> measures each of the loaded ROMs into one of the registers at reset time.
> 
> In combination with work in SeaBIOS and the kernel, this permits a fully 
> measured
> boot in a virtualised environment without the overhead of a full TPM
> implementation.

Will it be capable of workubg with edk2/OVMF/AVMF as well as SeaBIOS ?

> This version of the implementation depends on port io, but if there's 
> interest I'll
> add mmio as well.

So I guess this is the reason you've only enabled it for x86_64. Since we're
inventing an entirely new type of device here, not copying existing hardware,
I think it'd desirable if we created one that was supported across arches,
particularly aarch64, since that's the new hotness.  With the convergance
of both x86_64 and aarch64 to EFI, it'd be nice to aim for parity for this
trusted boot support too if practical.


> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index 98b4b1a..6a31392 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -1748,6 +1748,19 @@ Set QOM property @var{property} of object at location 
> @var{path} to value @var{v
>  ETEXI
>  
>      {
> +        .name       = "measurements",
> +        .args_type  = "",
> +        .params     = "",
> +        .help       = "Print system measurements",
> +        .mhandler.cmd = print_measurements,
> +    },
> +STEXI
> address@hidden measurements
> address@hidden measurements
> +Redirect Print system measurements
> +ETEXI
> +
> +    {

Thus since is just reporting info about a device, from a HMP POV,
it would fit better as an 'info' sub-command, eg 'info measurements'.
The QMP equivalent would be a 'query-measurements' command


> +void print_measurements(Monitor *mon, const QDict *qdict)
> +{
> +    int i, j;
> +    Object *obj = object_resolve_path_type("", TYPE_MEASUREMENTS, NULL);
> +    MeasurementState *s;
> +
> +    if (!obj) {
> +        return;
> +    }
> +
> +    s = MEASUREMENT(obj);
> +
> +    for (i = 0; i < 24; i++) {
> +        monitor_printf(mon, "0x%02x: ", i);
> +        for (j = 0; j < 20; j++) {
> +            monitor_printf(mon, "0x%02x ", s->measurements[i][j]);
> +        }
> +        monitor_printf(mon, "\n");
> +    }
> +}

The preferred approach to supporting monitor commands these
days is to first define a schema for the information to be
output in qapi-schema.json.  Then implement a QMP command
that returns an instance of the data structure you defined.
Finally the HMP command, would invoke the QMP command to
get the data to be printed.

For a fairly clear example of best practice, take a look at
these 2 commits:

  commit dc3dd0d2bed6edf3b60041f31200c674348168e9
  Author: Stefan Hajnoczi <address@hidden>
  Date:   Thu Feb 27 11:48:42 2014 +0100

    qmp: add query-iothreads command

  commit 62313160cb5b6bdfbd77a063e94a5a7d25e59f2b
  Author: Ting Wang <address@hidden>
  Date:   Fri Jun 26 16:07:13 2015 +0800

    hmp: add info iothreads command

between them, they illustrate the various files to modify
and the current preferred implementation style for monitor
commands.

> diff --git a/hw/misc/measurements.h b/hw/misc/measurements.h
> new file mode 100644
> index 0000000..65ad246
> --- /dev/null
> +++ b/hw/misc/measurements.h
> @@ -0,0 +1,2 @@
> +void print_measurements(Monitor *mon, const QDict *qdict);
> +void extend_data(int pcrnum, uint8_t *data, size_t len);

'extend_data' is rather too generic a name, for expose across
QEMU. Just add a "measurements_" prefix for any exported methods
from the measurements device.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|