Re: [vfio-users] OVMF secureboot question.

[Hagbard Celine]

2017-08-11 16:57 GMT+01:00, Laszlo Ersek :
> On 08/11/17 17:05, Hagbard Celine wrote:
>> 2017-08-11 13:28 GMT+01:00, Laszlo Ersek :
--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 

Re: [vfio-users] OVMF secureboot question.

[Laszlo Ersek]

On 08/11/17 17:05, Hagbard Celine wrote:
> 2017-08-11 13:28 GMT+01:00, Laszlo Ersek :
>> On 08/11/17 12:50, Hagbard Celine wrote:
>>> Hi, I used to update at every new version form kraxel.org, but at one
>>> point I had to stop updating due to secure-boot changes. As far as I
>>> could see, Q35 was needed for secure-boot on newer versions due to
>>> i440FX not emulating SMM.
>>>
>>> Today I did a search to see if anything had changed on the i440FX
>>> front, which it had not, but I fount this mail:
>>> https://lists.nongnu.org/archive/html/qemu-devel/2017-07/msg00942.html
>>> Wherein the important part for me is the following sub-quote:
>>> --snip
>>> OVMF's default upstream build works fine with
>>> i440fx. But, if you build OVMF with "-D SMM_REQUIRE" -- which is
>>> required for making "-D SECURE_BOOT_ENABLE" actually secure --,
>>> --snip
>>>
>>> Does this say that there exits a build that will let me update my OVMF
>>> and keep i440FX with not-actually-secure secure-boot as with older
>>> version? If so, where can I download this build?
>>>
>>> The reason I need this is:
>>> -I got software that needs to believe it runs on a secure-boot
>>> environment.
>>> -If I change to Q35 I get noticeable degraded performance in VM
>>> -Windows-licensing seriously dislikes having the chipset swapped, one
>>> time I almost totally lost my licence after changing chipset in Qemu.
>>
>> 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:

(1) When you update your firmware package, you get a new OVMF_CODE.fd
and a new OVMF_VARS.fd. Existing VMs will totally ignore the new
OVMF_VARS.fd. (Most of the time the "new" OVMF_VARS.fd template will be
totally identical to the version you had before.) Existing domains will
start using the new OVMF_CODE.fd when they are powered down, and booted
again. The new OVMF_CODE.fd will operate upon the VMs' preexistent
variable store files, which were created from the previously installed
OVMF_VARS.fd template.

Most of the time such upgrades are transparent, because the new
OVMF_CODE.fd is compatible with the previous OVMF_VARS.fd internal
layout. However, there are kinds of OVMF_CODE.fd changes that are
incompatible with preexistent varstore files. This incompatibility has
nice properties, such as:

- It is not predictable what feature or change will cause
incompatibility. It's case by case.

- If you try to boot an OVMF_CODE.fd upon a varstore file that is
incompatible with it, you won't get a nice error message. Most likely
your VM will crash horribly.

- Generally speaking, there is no way 

Re: [vfio-users] OVMF secureboot question.

[Hagbard Celine]

2017-08-11 13:28 GMT+01:00, Laszlo Ersek :
> On 08/11/17 12:50, Hagbard Celine wrote:
>> Hi, I used to update at every new version form kraxel.org, but at one
>> point I had to stop updating due to secure-boot changes. As far as I
>> could see, Q35 was needed for secure-boot on newer versions due to
>> i440FX not emulating SMM.
>>
>> Today I did a search to see if anything had changed on the i440FX
>> front, which it had not, but I fount this mail:
>> https://lists.nongnu.org/archive/html/qemu-devel/2017-07/msg00942.html
>> Wherein the important part for me is the following sub-quote:
>> --snip
>> OVMF's default upstream build works fine with
>> i440fx. But, if you build OVMF with "-D SMM_REQUIRE" -- which is
>> required for making "-D SECURE_BOOT_ENABLE" actually secure --,
>> --snip
>>
>> Does this say that there exits a build that will let me update my OVMF
>> and keep i440FX with not-actually-secure secure-boot as with older
>> version? If so, where can I download this build?
>>
>> The reason I need this is:
>> -I got software that needs to believe it runs on a secure-boot
>> environment.
>> -If I change to Q35 I get noticeable degraded performance in VM
>> -Windows-licensing seriously dislikes having the chipset swapped, one
>> time I almost totally lost my licence after changing chipset in Qemu.
>
> 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. Do it's
content change during normal operation of a Windows guest? My idea was
keeping a backup that I diff against the live version, to add a little
more security than I have today.


> If you decide to build OVMF from source, and have used Kraxel's RPMs
> thus far, a caveat: don't forget to add -D FD_SIZE_2MB as well to your
> build command line. Upstream OVMF has switched to a 4MB combined flash
> size, which is not compatible with preexistent varstore files that were
> created for a 2MB combined flash size. (This is another example why the
> "nvram" stanza in "/etc/libvirt/qemu.conf" associates firmware binaries
> with their matching varstore templates.) So, if you plan to switch over
> an existent domain (preserving its current varstore file), then pass -D
> FD_SIZE_2MB too.
>
> Thanks,
> Laszlo
>

Got my new OVMF build now, thanks.

___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] OVMF secureboot question.

[Laszlo Ersek]

On 08/11/17 12:50, Hagbard Celine wrote:
> Hi, I used to update at every new version form kraxel.org, but at one
> point I had to stop updating due to secure-boot changes. As far as I
> could see, Q35 was needed for secure-boot on newer versions due to
> i440FX not emulating SMM.
> 
> Today I did a search to see if anything had changed on the i440FX
> front, which it had not, but I fount this mail:
> https://lists.nongnu.org/archive/html/qemu-devel/2017-07/msg00942.html
> Wherein the important part for me is the following sub-quote:
> --snip
> OVMF's default upstream build works fine with
> i440fx. But, if you build OVMF with "-D SMM_REQUIRE" -- which is
> required for making "-D SECURE_BOOT_ENABLE" actually secure --,
> --snip
> 
> Does this say that there exits a build that will let me update my OVMF
> and keep i440FX with not-actually-secure secure-boot as with older
> version? If so, where can I download this build?
> 
> The reason I need this is:
> -I got software that needs to believe it runs on a secure-boot environment.
> -If I change to Q35 I get noticeable degraded performance in VM
> -Windows-licensing seriously dislikes having the chipset swapped, one
> time I almost totally lost my licence after changing chipset in Qemu.

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).

If you decide to build OVMF from source, and have used Kraxel's RPMs
thus far, a caveat: don't forget to add -D FD_SIZE_2MB as well to your
build command line. Upstream OVMF has switched to a 4MB combined flash
size, which is not compatible with preexistent varstore files that were
created for a 2MB combined flash size. (This is another example why the
"nvram" stanza in "/etc/libvirt/qemu.conf" associates firmware binaries
with their matching varstore templates.) So, if you plan to switch over
an existent domain (preserving its current varstore file), then pass -D
FD_SIZE_2MB too.

Thanks,
Laszlo

___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users