Re: [PATCH] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

2024-12-09 Thread Ani Sinha
On Mon, Dec 2, 2024 at 1:17 PM Ani Sinha  wrote:
>
>
>
> > On 29 Nov 2024, at 3:42 PM, Philippe Mathieu-Daudé  
> > wrote:
> >
> > On 29/11/24 10:16, Ani Sinha wrote:
> >> VM firmware update is a mechanism where the virtual machines can use their
> >> preferred and trusted firmware image in their execution environment without
> >> having to depend on a untrusted party to provide the firmware bundle. This 
> >> is
> >> particularly useful for confidential virtual machines that are deployed in 
> >> the
> >> cloud where the tenant and the cloud provider are two different entities. 
> >> In
> >> this scenario, virtual machines can bring their own trusted firmware image
> >> bundled as a part of their filesystem (using UKIs for example[1]) and then 
> >> use
> >> this hypervisor interface to update to their trusted firmware image. This 
> >> also
> >> allows the guests to have a consistent measurements on the firmware image.
> >> This change introduces basic support for the fw-cfg based hypervisor 
> >> interface
> >> and the corresponding device. The change also includes the
> >> specification document for this interface. The interface is made generic
> >> enough so that guests are free to use their own ABI to pass required
> >> information between initial and trusted execution contexts (where they are
> >> running their own trusted firmware image) without the hypervisor getting
> >> involved in between. In subsequent patches, we will introduce other minimal
> >> changes on the hypervisor that are required to make the mechanism work.
> >> [1] See systemd pull requests https://github.com/systemd/systemd/pull/35091
> >> and https://github.com/systemd/systemd/pull/35281 for some discussions on
> >> how we can bundle firmware image within an UKI.
> >> CC: Alex Graf 
> >> CC: Paolo Bonzini 
> >> CC: Gerd Hoffman 
> >> CC: Igor Mammedov 
> >> CC: Vitaly Kuznetsov 
> >> Signed-off-by: Ani Sinha 

I know we are in code freeze but I would appreciate any more feedback
on this patch so that when the freeze lifts, we may merge it.

> >> ---
> >>  MAINTAINERS  |   9 +++
> >>  docs/specs/index.rst |   1 +
> >>  docs/specs/vmfwupdate.rst| 109 +
> >>  hw/misc/meson.build  |   2 +
> >>  hw/misc/vmfwupdate.c | 152 +++
> >>  include/hw/misc/vmfwupdate.h | 103 
> >>  6 files changed, 376 insertions(+)
> >>  create mode 100644 docs/specs/vmfwupdate.rst
> >>  create mode 100644 hw/misc/vmfwupdate.c
> >>  create mode 100644 include/hw/misc/vmfwupdate.h
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index 095420f8b0..cd4135fb5b 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -2531,6 +2531,15 @@ F: include/hw/acpi/vmgenid.h
> >>  F: docs/specs/vmgenid.rst
> >>  F: tests/qtest/vmgenid-test.c
> >>  +VM Firmware Update
> >> +M: Ani Sinha 
> >> +M: Alex Graf 
> >> +M: Paolo Bonzini 
> >> +S: Maintained
> >> +F: hw/misc/vmfwupdate.c
> >> +F: include/hw/misc/vmfwupdate.h
> >> +F: docs/specs/vmfwupdate.rst
> >> +
> >>  LED
> >>  M: Philippe Mathieu-Daudé 
> >>  S: Maintained
> >> diff --git a/docs/specs/index.rst b/docs/specs/index.rst
> >> index ff5a1f03da..cbda7e0398 100644
> >> --- a/docs/specs/index.rst
> >> +++ b/docs/specs/index.rst
> >> @@ -34,6 +34,7 @@ guest hardware that is specific to QEMU.
> >> virt-ctlr
> >> vmcoreinfo
> >> vmgenid
> >> +   vmfwupdate
> >> rapl-msr
> >> rocker
> >> riscv-iommu
> >> diff --git a/docs/specs/vmfwupdate.rst b/docs/specs/vmfwupdate.rst
> >> new file mode 100644
> >> index 00..3a36ca14c7
> >> --- /dev/null
> >> +++ b/docs/specs/vmfwupdate.rst
> >> @@ -0,0 +1,109 @@
> >> +VMFWUPDATE INTERFACE SPECIFICATION
> >> +##
> >> +
> >> +Introduction
> >> +
> >> +
> >> +``Vmfwupdate`` is an extension to ``fw-cfg`` that allows guests to 
> >> replace early boot
> >> +code in their virtual machine. Through a combination of vmfwupdate and
> >> +hypervisor stack knowledge, guests can deterministically replace the 
> >> launch
> >> +payload for guests. This is useful for environments like SEV-SNP where the
> >> +launch payload becomes the launch digest. Guests can use vmfwupdate to 
> >> provide
> >> +a measured, full guest payload (BIOS image, kernel, initramfs, kernel
> >> +command line) to the virtual machine which enables them to easily reason 
> >> about
> >> +integrity of the resulting system.
> >> +For more information, please see the `KVM Forum 2024 presentation 
> >> `__
> >> +about this work from the authors [1]_.
> >> +
> >> +
> >> +.. _KVMFORUM: https://www.youtube.com/watch?v=VCMBxU6tAto
> >> +
> >> +Base Requirements
> >> +*
> >> +
> >> +#. **fw-cfg**:
> >> + The target system must provide a ``fw-cfg`` interface. For x86 based
> >> + environments, this ``fw-cfg`` interface must be accessible through 
> >> PIO ports
> >> + 0x510 and 0x511. The ``fw-cfg`` interface 

Re: [PATCH] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

2024-12-01 Thread Ani Sinha



> On 29 Nov 2024, at 3:42 PM, Philippe Mathieu-Daudé  wrote:
> 
> On 29/11/24 10:16, Ani Sinha wrote:
>> VM firmware update is a mechanism where the virtual machines can use their
>> preferred and trusted firmware image in their execution environment without
>> having to depend on a untrusted party to provide the firmware bundle. This is
>> particularly useful for confidential virtual machines that are deployed in 
>> the
>> cloud where the tenant and the cloud provider are two different entities. In
>> this scenario, virtual machines can bring their own trusted firmware image
>> bundled as a part of their filesystem (using UKIs for example[1]) and then 
>> use
>> this hypervisor interface to update to their trusted firmware image. This 
>> also
>> allows the guests to have a consistent measurements on the firmware image.
>> This change introduces basic support for the fw-cfg based hypervisor 
>> interface
>> and the corresponding device. The change also includes the
>> specification document for this interface. The interface is made generic
>> enough so that guests are free to use their own ABI to pass required
>> information between initial and trusted execution contexts (where they are
>> running their own trusted firmware image) without the hypervisor getting
>> involved in between. In subsequent patches, we will introduce other minimal
>> changes on the hypervisor that are required to make the mechanism work.
>> [1] See systemd pull requests https://github.com/systemd/systemd/pull/35091
>> and https://github.com/systemd/systemd/pull/35281 for some discussions on
>> how we can bundle firmware image within an UKI.
>> CC: Alex Graf 
>> CC: Paolo Bonzini 
>> CC: Gerd Hoffman 
>> CC: Igor Mammedov 
>> CC: Vitaly Kuznetsov 
>> Signed-off-by: Ani Sinha 
>> ---
>>  MAINTAINERS  |   9 +++
>>  docs/specs/index.rst |   1 +
>>  docs/specs/vmfwupdate.rst| 109 +
>>  hw/misc/meson.build  |   2 +
>>  hw/misc/vmfwupdate.c | 152 +++
>>  include/hw/misc/vmfwupdate.h | 103 
>>  6 files changed, 376 insertions(+)
>>  create mode 100644 docs/specs/vmfwupdate.rst
>>  create mode 100644 hw/misc/vmfwupdate.c
>>  create mode 100644 include/hw/misc/vmfwupdate.h
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 095420f8b0..cd4135fb5b 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -2531,6 +2531,15 @@ F: include/hw/acpi/vmgenid.h
>>  F: docs/specs/vmgenid.rst
>>  F: tests/qtest/vmgenid-test.c
>>  +VM Firmware Update
>> +M: Ani Sinha 
>> +M: Alex Graf 
>> +M: Paolo Bonzini 
>> +S: Maintained
>> +F: hw/misc/vmfwupdate.c
>> +F: include/hw/misc/vmfwupdate.h
>> +F: docs/specs/vmfwupdate.rst
>> +
>>  LED
>>  M: Philippe Mathieu-Daudé 
>>  S: Maintained
>> diff --git a/docs/specs/index.rst b/docs/specs/index.rst
>> index ff5a1f03da..cbda7e0398 100644
>> --- a/docs/specs/index.rst
>> +++ b/docs/specs/index.rst
>> @@ -34,6 +34,7 @@ guest hardware that is specific to QEMU.
>> virt-ctlr
>> vmcoreinfo
>> vmgenid
>> +   vmfwupdate
>> rapl-msr
>> rocker
>> riscv-iommu
>> diff --git a/docs/specs/vmfwupdate.rst b/docs/specs/vmfwupdate.rst
>> new file mode 100644
>> index 00..3a36ca14c7
>> --- /dev/null
>> +++ b/docs/specs/vmfwupdate.rst
>> @@ -0,0 +1,109 @@
>> +VMFWUPDATE INTERFACE SPECIFICATION
>> +##
>> +
>> +Introduction
>> +
>> +
>> +``Vmfwupdate`` is an extension to ``fw-cfg`` that allows guests to replace 
>> early boot
>> +code in their virtual machine. Through a combination of vmfwupdate and
>> +hypervisor stack knowledge, guests can deterministically replace the launch
>> +payload for guests. This is useful for environments like SEV-SNP where the
>> +launch payload becomes the launch digest. Guests can use vmfwupdate to 
>> provide
>> +a measured, full guest payload (BIOS image, kernel, initramfs, kernel
>> +command line) to the virtual machine which enables them to easily reason 
>> about
>> +integrity of the resulting system.
>> +For more information, please see the `KVM Forum 2024 presentation 
>> `__
>> +about this work from the authors [1]_.
>> +
>> +
>> +.. _KVMFORUM: https://www.youtube.com/watch?v=VCMBxU6tAto
>> +
>> +Base Requirements
>> +*
>> +
>> +#. **fw-cfg**:
>> + The target system must provide a ``fw-cfg`` interface. For x86 based
>> + environments, this ``fw-cfg`` interface must be accessible through PIO 
>> ports
>> + 0x510 and 0x511. The ``fw-cfg`` interface does not need to be 
>> announced as part
>> + of system device tables such as DSDT. The ``fw-cfg`` interface must 
>> support the
>> + DMA interface. It may only support the DMA interface for write 
>> operations.
>> +
>> +#. **BIOS region**:
>> + The hypervisor must provide a BIOS region which may be
>> + statically sized. Through vmfwupdate, the guest is able to atomically 
>> replace
>> + its contents. The 

Re: [PATCH] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

2024-11-29 Thread Philippe Mathieu-Daudé

On 29/11/24 10:16, Ani Sinha wrote:

VM firmware update is a mechanism where the virtual machines can use their
preferred and trusted firmware image in their execution environment without
having to depend on a untrusted party to provide the firmware bundle. This is
particularly useful for confidential virtual machines that are deployed in the
cloud where the tenant and the cloud provider are two different entities. In
this scenario, virtual machines can bring their own trusted firmware image
bundled as a part of their filesystem (using UKIs for example[1]) and then use
this hypervisor interface to update to their trusted firmware image. This also
allows the guests to have a consistent measurements on the firmware image.

This change introduces basic support for the fw-cfg based hypervisor interface
and the corresponding device. The change also includes the
specification document for this interface. The interface is made generic
enough so that guests are free to use their own ABI to pass required
information between initial and trusted execution contexts (where they are
running their own trusted firmware image) without the hypervisor getting
involved in between. In subsequent patches, we will introduce other minimal
changes on the hypervisor that are required to make the mechanism work.

[1] See systemd pull requests https://github.com/systemd/systemd/pull/35091
and https://github.com/systemd/systemd/pull/35281 for some discussions on
how we can bundle firmware image within an UKI.

CC: Alex Graf 
CC: Paolo Bonzini 
CC: Gerd Hoffman 
CC: Igor Mammedov 
CC: Vitaly Kuznetsov 
Signed-off-by: Ani Sinha 
---
  MAINTAINERS  |   9 +++
  docs/specs/index.rst |   1 +
  docs/specs/vmfwupdate.rst| 109 +
  hw/misc/meson.build  |   2 +
  hw/misc/vmfwupdate.c | 152 +++
  include/hw/misc/vmfwupdate.h | 103 
  6 files changed, 376 insertions(+)
  create mode 100644 docs/specs/vmfwupdate.rst
  create mode 100644 hw/misc/vmfwupdate.c
  create mode 100644 include/hw/misc/vmfwupdate.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 095420f8b0..cd4135fb5b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2531,6 +2531,15 @@ F: include/hw/acpi/vmgenid.h
  F: docs/specs/vmgenid.rst
  F: tests/qtest/vmgenid-test.c
  
+VM Firmware Update

+M: Ani Sinha 
+M: Alex Graf 
+M: Paolo Bonzini 
+S: Maintained
+F: hw/misc/vmfwupdate.c
+F: include/hw/misc/vmfwupdate.h
+F: docs/specs/vmfwupdate.rst
+
  LED
  M: Philippe Mathieu-Daudé 
  S: Maintained
diff --git a/docs/specs/index.rst b/docs/specs/index.rst
index ff5a1f03da..cbda7e0398 100644
--- a/docs/specs/index.rst
+++ b/docs/specs/index.rst
@@ -34,6 +34,7 @@ guest hardware that is specific to QEMU.
 virt-ctlr
 vmcoreinfo
 vmgenid
+   vmfwupdate
 rapl-msr
 rocker
 riscv-iommu
diff --git a/docs/specs/vmfwupdate.rst b/docs/specs/vmfwupdate.rst
new file mode 100644
index 00..3a36ca14c7
--- /dev/null
+++ b/docs/specs/vmfwupdate.rst
@@ -0,0 +1,109 @@
+VMFWUPDATE INTERFACE SPECIFICATION
+##
+
+Introduction
+
+
+``Vmfwupdate`` is an extension to ``fw-cfg`` that allows guests to replace 
early boot
+code in their virtual machine. Through a combination of vmfwupdate and
+hypervisor stack knowledge, guests can deterministically replace the launch
+payload for guests. This is useful for environments like SEV-SNP where the
+launch payload becomes the launch digest. Guests can use vmfwupdate to provide
+a measured, full guest payload (BIOS image, kernel, initramfs, kernel
+command line) to the virtual machine which enables them to easily reason about
+integrity of the resulting system.
+For more information, please see the `KVM Forum 2024 presentation 
`__
+about this work from the authors [1]_.
+
+
+.. _KVMFORUM: https://www.youtube.com/watch?v=VCMBxU6tAto
+
+Base Requirements
+*
+
+#. **fw-cfg**:
+ The target system must provide a ``fw-cfg`` interface. For x86 based
+ environments, this ``fw-cfg`` interface must be accessible through PIO 
ports
+ 0x510 and 0x511. The ``fw-cfg`` interface does not need to be announced 
as part
+ of system device tables such as DSDT. The ``fw-cfg`` interface must 
support the
+ DMA interface. It may only support the DMA interface for write operations.
+
+#. **BIOS region**:
+ The hypervisor must provide a BIOS region which may be
+ statically sized. Through vmfwupdate, the guest is able to atomically 
replace
+ its contents. The BIOS region must be mapped as read-write memory. In a
+ SEV-SNP environment, the BIOS region must be mapped as private memory at
+ launch time.
+
+Fw-cfg Files
+
+
+Guests drive vmfwupdate through special ``fw-cfg`` files that control its flow
+followed by a standard system reset operation. When vmfwupdate is available,
+it provides the following ``fw-cfg`` files:
+
+* ``vmfwupdate/cap`