[libvirt-users] [Fwd: UEFI NVRAM variables]

[Laszlo Ersek]

On 07/13/17 13:26, Laszlo Ersek wrote:
> On 07/13/17 10:19, Andrea Bolognani wrote:
>> -------- Forwarded Message --------
>> From: Thomas Meyer <thomas at m3y3r.de>
>> To: libvirt-users at redhat.com
>> Subject: [libvirt-users] UEFI NVRAM variables
>> Date: Wed, 12 Jul 2017 07:49:43 +0200

>>> how do I set the BootOrder variable in an NVRAM file for UEFI boot?

>>> Are there a tool available to manipulate the UEFI variables from the outside?

> Either way, massaging guest-produced data from the host side, be the
> data "UEFI variable content" or "disk image content", is also a security
> question. So the only one really feasible approach here would be a
> libguestfs-like tool that
> - booted a guest on top of the variable store,
> - implemented a kind of "firmware guest agent" that manipulated the
> variables "from the inside",
> - and used custom commands over virtio-serial, between host and guest.
> 
> As I said, a large project.

That said, "all is not lost", if your use case is simple enough, and you
don't mind a bit of ad-hoc coding. The following is viable right now,
from a POSIX shell script:

(1) Generate a UEFI shell script that uses the BCFG command.

They UEFI shell spec can be found at
<http://www.uefi.org/specifications>. (No registration or payment
needed, just go ahead and download it.)

(2) Call the file you generate "startup.nsh". Use CRLF line breaks, and
read the UEFI Shell Spec on "startup.nsh".

(3) Format a small disk image (MBR or GPT partition table, single FAT32
partition) with this script on it. Use guestfish for this.

(4) Boot OVMF as follows:
- use the split OVMF_CODE.fd binary that you would otherwise use
- use the variable store that otherwise belongs to your virtual machine
(managed by libvirt) -- make sure the VM is currently offline
- specify no disk image, and disable networking with "-net none"

This will drop you to the UEFI shell in the guest, and the shell should
automatically locate and run your script called "startup.nsh".

Alternatives to the above steps, on varying levels of hackery:
- replace libguestfs with mtools, or
- replace disk image formatting entirely with QEMU's vvfat protocol
  driver (so the guest would get the generated script directly from the
  host filesystem)
- replace disk image emulation entirely with serial IO communication;
  that is, use "expect", and send the commands to the UEFI shell as if
  by typing them on the serial console.

Thanks,
Laszlo