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
> +@item measurements
> +@findex 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 <stefa...@redhat.com>
Date: Thu Feb 27 11:48:42 2014 +0100
qmp: add query-iothreads command
commit 62313160cb5b6bdfbd77a063e94a5a7d25e59f2b
Author: Ting Wang <kathy.wangt...@huawei.com>
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 :|
