BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//pretalx.com//kvm-forum-2024//speaker//SAXB9H
BEGIN:VTIMEZONE
TZID:CET
BEGIN:STANDARD
DTSTART:20001029T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-kvm-forum-2024-HJSKRQ@pretalx.com
DTSTART;TZID=CET:20240922T134500
DTEND;TZID=CET:20240922T141500
DESCRIPTION:All virtual machines\, in the most common use case\, use system
  firmware present in the ‘standard’ path inside the hypervisor host wh
 ile booting. For BIOS-booted VM\, the firmware is normally SeaBIOS-based a
 nd for UEFI-booted VMs\, it is edk2-based. Currently\, when a cloud VM is 
 launched\, the firmware binary is supplied by the cloud provider and the e
 nd user has no control over it. For confidential VMs\, this represents pro
 blems both for the end user and for the cloud provider.\n- The end user ge
 ts firmware measurements for the attestation purposes\, however\, without 
 an ability to provide a self built (or trusted) binary\, these measurement
 s can only indicate that the firmware hasn’t changed. The end user has t
 o implicitly place some trust in the cloud-provider supplied firmware bina
 ry.\n- The cloud provider can’t update the firmware (e.g. to fix a vulne
 rability) without disturbing user workloads. As firmware is included into 
 launch measurements\, just swapping the firmware will cause attestation er
 rors. The problem is even worse for embargoed vulnerabilities.\n\nThis tal
 k describes a method of supplying system (UEFI) firmware for VMs as part o
 f the VM disk image. The cloud-provider would not need to look into/get ac
 cess to the VM disk image. The VM will use the proposed mechanism to provi
 de the firmware binary to the hypervisor. The hypervisor will use this mec
 hanism to install the firmware binary into the guest ROM and regenerate th
 e VM. Our initial approach will be solely based on QEMU/KVM/EDK2/UKI. The 
 approach should eventually become widely adopted across the industry (othe
 r cloud providers\, hypervisors/VMMs\, etc ).\nOur approach has several ad
 vantages compared to using an IGVM container image with an embedded firmwa
 re passed to the hypervisor when starting the guest. \n- First of all\, th
 e firmware image is provided along with the guest VM image (using a UKI ad
 d-on). Therefore\, the guest image and the firmware binary can be packaged
  together as one single unit. There is no need to store the firmware blob 
 (inside an IGVM container) somewhere separately in the hypervisor host to 
 pass it to the hypervisor when starting the guest. \n- Secondly\, the requ
 est to the hypervisor to install the firmware image is directly initiated 
 by the guest. Therefore\, the guest controls when to upgrade the firmware 
 and which firmware image to upgrade to. There is no need for the hyperviso
 r to make any decision on this issue. The hypervisor also does not need ac
 cess to the VM image either. \n- Lastly\, it is possible to upgrade the fi
 rmware without re-deploying a new guest VM image (and a new IGVM image con
 taining the new firmware image) . Upgrading to a new firmware image is pos
 sible by an already existing VM spawned from the current VM image by simpl
 y updating the UKI firmware add-on to a new updated PE binary and using th
 e mechanism to install it in the guest ROM.\n\nWe intend to give a demo of
  our prototype in action.
DTSTAMP:20260309T214942Z
LOCATION:Hall C+D
SUMMARY:Empowering confidential VMs in the cloud to use their own firmware 
 upon instantiation. - Anirban (Ani) Sinha\, Alexander Graf\, Vitaly Kuznet
 sov
URL:https://pretalx.com/kvm-forum-2024/talk/HJSKRQ/
END:VEVENT
END:VCALENDAR