[vfio-users] OVMF secureboot question.

[Hagbard Celine]

2017-08-11 16:57 GMT+01:00, Laszlo Ersek <lersek at redhat.com>:
> On 08/11/17 17:05, Hagbard Celine wrote:
>> 2017-08-11 13:28 GMT+01:00, Laszlo Ersek <lersek at redhat.com>:
--shortening a bit
>>> Some time after the implementation of SMM in all of KVM, QEMU (q35
>>> only), and OVMF, all of the OVMF builds that I have any connection to
>>> started limiting the Secure Boot feature to builds that also enforced
>>> SMM_REQUIRE. This is because we shouldn't distribute a fw binary any
>>> longer that offers the Secure Boot feature without the means to enforce
>>> its security.
>>>
>>> If you consciously want to do this, you can build OVMF from source. Add
>>> -D SECURE_BOOT_ENABLE to the build command line, without adding -D
>>> SMM_REQUIRE. The resultant firmware binary will offer the Secure Boot
>>> software interfaces, and it will run on both i440fx and Q35. However, a
>>> malicious guest OS component will be able to circumvent any Secure Boot
>>> settings, via direct hardware access to the varstore pflash chip, and/or
>>> to the S3 LockBox data structure in normal RAM (if you use S3 within the
>>> guest).
>>
>> As I understand varstore pflash is the OVMF_VARS.fd file.
>
> No, OVMF_VARS.fd is a varstore *template*. It is a preformatted,
> pristine / "logically empty" variable store file that is built as part
> of the build process, and is tied to the other build output file, the
> OVMF_CODE.fd binary executable.
>
> "OVMF_VARS.fd" is saved from the build as a *template*, for new virtual
> machines that are created with "OVMF_CODE.fd" being their firmware
> binary. "OVMF_CODE.fd" may be in use (read-only) by several VMs at the
> time. "OVMF_VARS.fd" is *never* in use by any VM at all; it is used by
> libvirt (or by custom QEMU wrapper scripts) to instantiate a private
> variable store file for the VM being created. Once created, the VM never
> looks at "OVMF_VARS.fd", it only uses its private copy (which
> immediately diverges from the pristine template, of course) under
> /var/lib/libvirt/qemu/nvram/.
>
>> Do it's
>> content change during normal operation of a Windows guest?
>
> "OVMF_VARS.fd" should never change, as it is a template.
>
> The VM's private copy of it (that is, the VM's own variable store file)
> changes all the time, even without booting a guest OS. Modules in the
> firmware read and write non-volatile UEFI variables in it during boot.
>
> Some user-visible configuration lives in it too, of course; UEFI boot
> options, Secure Boot certificates, etc.
>
>> My idea was
>> keeping a backup that I diff against the live version, to add a little
>> more security than I have today.
>
> I'm not sure I understand clearly what you mean to back up, so let me
> approach this from to angles:

I see that I could have saved you a lot of typing by explaining my
reasoning a little better, sorry for that.

--cutting to 2nd angle which is the relevant one (but thanks for the lesson)

> (2) With regard to backing up a live variable store file (i.e. one that
> lives under /var/lib/libvirt/qemu/nvram). This is a valid idea, but the
> "backup" scope is much larger than that. Normally what a user wants here
> is snapshots of the entire VM, including domain XML configuration,
> varstore, disk(s), and if the VM was running at the time of
> snapshotting, memory contents. Unfortunately, neither QEMU nor libvirt
> support snapshotting pflash chips (... in a sensible manner), so this
> won't work. (Newer versions of libvirt will even openly refuse a
> snapshot request.)

The idea about backing up varstore came form you pointing out my
varstore is not protected from malicious software in guest. My
reasoning was that UEFI boot options and Secure Boot certificates
would be something that should not change during normal operation of
Windows. And that this would be the things malicious software would
try to change. Thus If I could use a backup of the VM's varstore and
diff it against the version in use either while running, or after each
shutdown in worst case; I would at-leas have a kind of tripwire to
replace the lock-down I do not have. What I did not count on was the
variables you talk about.

> So, for now, if you want to back up your varstore file separately,
> that's not a bad idea. But, it's also not tragic if you lose a varstore
> file; you (and libvirt) can recreate it from the pristine template, and
> then the firmware and the guest OS can recreate most of the variables in
> it. (You can re-enroll the Secure Boot certificates manually.)
>
> Re: diffing varstore files between each other: the output is mostly
> unconsumable for humans. The varstore wire format is the composition of
> three or four binary abstractions (= layers of drivers in the firmware).
> It's basically an opaque hexdump that is hard to read even if you know
> exactly what artifact you are looking for.
>
With a great possibility of making a even bigger fool of myself, or
maybe I do not classify as human;
I find it quite transparent(please nobody read this as authoritative).
First I see a header for for Secure Boot certificates.
Then comes the KEK, db and PK, with the dbx somewhere between or right after.
Then comes the UEFI boot and other settings form bios-screen.
And at the end of that part there seems to be added a small section
for every boot cycle, which I guess is windows setting it self to
first-pri for next boot at shutdown.
And then, If I'm very lucky there are the variables that I did not
know about approximately in the middle of the file, in the part mostly
filled with FF.

If this is remotely correct, I could use a backup of the varstore and
do a "cmp --bytes=X backup.fd vm.fd". Where X is a offset just before
the part that keeps being added to every boot-cycle.