From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNqiS-0004A7-Ft for qemu-devel@nongnu.org; Thu, 14 Jul 2016 20:10:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNqiR-0001d5-4M for qemu-devel@nongnu.org; Thu, 14 Jul 2016 20:10:52 -0400 Received: from mail-yw0-x234.google.com ([2607:f8b0:4002:c05::234]:33567) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNqiP-0001cT-SA for qemu-devel@nongnu.org; Thu, 14 Jul 2016 20:10:51 -0400 Received: by mail-yw0-x234.google.com with SMTP id v186so26484771ywd.0 for ; Thu, 14 Jul 2016 17:10:48 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160714145424.GA21479@redhat.com> References: <1466725019-3228-1-git-send-email-mjg59@coreos.com> <20160714145424.GA21479@redhat.com> From: Matthew Garrett Date: Fri, 15 Jul 2016 09:10:47 +0900 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH] hw/misc: Add simple measurement hardware List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org On Thu, Jul 14, 2016 at 11:54 PM, Daniel P. Berrange wrote: > On Thu, Jun 23, 2016 at 04:36:59PM -0700, Matthew Garrett wrote: > > 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 ? > > Yes, that will work fine. > > 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. > Fair. I can redo this so it's mmio everywhere. > > > 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 > Ok. > > > +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. > Ok, thanks for the pointers! > > > 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. > Will do. Thanks for the feedback!