Hi, > > +# @data: variable value, encoded as hex string. > > I understand this is a blob. We commonly use base64 for that. Why not > here?
It's an existing format already supported by other tools. Guess I should add that to the preamble. > > +# @digest: variable certificate digest. Used to verify the signature > > +# of updates for authenticated variables. > > How to create and verify these digests will be obvious enough to users > of this interface? Well, no. It's a somewhat complicated story ... UEFI has two kinds of authenticated variables. First, the secure boot variables (PK, KEK, db, dbx). These have hard-coded rules, the rule most relevant in practice is that signed update requests for the 'db' and 'dbx' variables are checked against the 'KEK' certificate database. For other authenticated variables UEFI essentially remembers the certificate when the variable is created, and any update / delete requests need a signature from the same certificate (simplified a bit to keep it short, the actual rules are more complicated, details are in the UEFI spec). This digest handles the "remembers the certificate" part. In practice the second kind of authenticated variables is rarely used. I have yet to see a piece of software actually using that in practice (other than the test case I have written). Also note that this is *not* part of the QMP interface. The driver uses this to store the efi variable store in json format on disk (see var-service-json.c in this patch). Adding support for reading/writing uefi variables is something we might add to the monitor in the future. Should that happen it is not clear whenever such an interface would actually use the raw 'UefiVariable' struct or if higher-level interfaces would be more useful. For example a command to query whenever the guest has secure boot turned on. take care, Gerd
