On Tue, Apr 10, 2018 at 11:20:33AM +0100, Daniel P. Berrangé wrote:
On Sat, Apr 07, 2018 at 02:01:17AM +0200, Laszlo Ersek wrote:
Add a schema that describes the properties of virtual machine firmware.
Each firmware executable installed on a host system should come with a JSON file that conforms to this schema, and informs the management applications about the firmware's properties.
In addition, a configuration directory with symlinks to the JSON files should exist, with the symlinks carefully named to reflect a priority order. Management applications can then search this directory in priority order for the first firmware executable that satisfies their search criteria. The found JSON file provides the management layer with domain configuration bits that are required to run the firmware binary.
diff --git a/qapi/firmware.json b/qapi/firmware.json new file mode 100644 index 000000000000..f267240f44dd --- /dev/null +++ b/qapi/firmware.json
[snip]
+{ 'struct' : 'SystemFirmware', + 'data' : { 'executable' : 'FirmwareFile', + 'type' : 'SystemFirmwareType', + 'targets' : [ 'str' ], + 'sysfw-map' : 'FirmwareMapping', + '*nvram-slots' : [ 'NVRAMSlot' ], + '*supports-uefi-secure-boot' : 'bool', + '*supports-amd-sev' : 'bool', + '*supports-acpi-s3' : 'bool', + '*supports-acpi-s4' : 'bool' } }
Elsewhere in the thread I mentioned that I think we should try to use a union approach to isolate which information is relevant to "flash" loader format and which is relevant to "memory" and "kernel". To try to illustrate what I mean by that I've knocked up an alternative structure. I also incorporated the points about features & target/machine types. I've left out the read/write/etc fields, but they could be put back in at the relevant position
{ 'enum' : 'SystemFirmwareType', 'data' : [ 'bios', 'slof', 'uboot', 'uefi' ] }
{ 'enum' : 'SystemFirmwareDevice', 'data' : [ 'memory', 'kernel', 'flash' ] }
{ 'enum' : 'SystemFirmwareArchitecture', 'data': ['x86_64', 'i386', ..etc.. ] }
{ 'enum' : 'SystemFirmwareFeature', 'data': ['acpi-s3', 'acpi-s5', 'secure-boot', 'amd-sev' ]}
## Struct(s) for device==memory
{ 'struct': 'SystemFirmwareBinaryMemory', 'data': { 'pathname': 'str' } }
## Struct(s) for device==kernel
{ 'struct': 'SystemFirmwareBinaryKernel', 'data': { 'pathname': 'str' } }
## Struct(s) for device==flash
{ 'struct': 'SystemFirmwareBinaryFlashFile', 'data': { 'filename': 'str', 'format': 'BlockdevDriver' } }
{ 'struct': 'SystemFirmwareBinaryFlashCode', 'base': 'SystemFirmwareBinaryFlashFile' }
{ 'struct': 'SystemFirmwareBinaryFlashVars', 'base': 'SystemFirmwareBinaryFlashFile', 'data': { 'secure-boot-key-enroll': 'bool' } }
{ 'struct': 'SystemFirmwareBinaryFlash', 'data': { 'code': 'SystemFirmwareBinaryFlashCode', 'vars': ['SystemFirmwareBinaryFlashVars' ] } }
## Discriminated struct for different loading approaches
{ 'union': 'SystemFirmwareBinary', 'base': { 'device': 'SystemFirmwareDevice' }, 'discriminator': 'device', 'data': { 'memory': 'SystemFirmwareBinaryMemory', 'kernel': 'SystemFirmwareBinaryKernel', 'flash': 'SystemFirmwareBinaryFlash' } }
{ 'struct' : 'SystemFirmwareTarget', 'data': { 'architecture': 'SystemFirmwareArchitecture', 'machines': [ 'str' ] } }
{ 'struct' : 'SystemFirmware', 'data' : { 'description' : 'str', 'type' : 'SystemFirmwareType', 'binary' : 'SystemFirmwareBinary', 'targets' : [ 'SystemFirmwareTarget' ], 'features' : ['SystemFirmwareFeature'] } }
# Examples: # # { # 'description': 'SeaBIOS 256k', # 'type': 'bios', # 'binary': { # 'type': 'memory', # 'filename': '/path/to/seabios/rom-256k', # } # 'targets': { # 'x86_64': [ "pc", "q35"], # 'i386': [ "pc", "q35"], # } # 'features': ['acpi-s3', 'acpi-s5'], # } # { # 'description': 'SeaBIOS 128k', # 'type': 'bios', # 'binary': { # 'type': 'memory', # 'filename': '/path/to/seabios/rom-128k', # } # 'targets': { # 'x86_64': [ "isapc"], # 'i386': [ "isapc"], # } # 'features': [], # } # { # 'description': 'OVMF', # 'type': 'uefi' # 'binary': { # 'type': 'flash', # 'code': { # 'filename': '/usr/share/OVMF/OVMF_CODE.secboot.fd', # 'format': 'raw', # }, # 'vars': [ # { # 'filename': '/usr/share/OVMF/OVMF_VARS.fd', # 'format': 'raw', # 'secure=boot-key-enroll': false, # }, # { # 'filename': '/usr/share/OVMF/OVMF_VARS.secboot.fd', # 'format': 'raw', # 'secure=boot-key-enroll': true, # }
It occurs to me that we are actually over-thinking things, by making it possible to list a choice of vars files per firmware. We could remove this special case by just having separate tpo level firmware entries and a main feature flag to say if it is enrolled or not - see below example
# ], # }, # 'targets': { # 'x86_64': [ "q35"], # } # 'features': ['acpi-s3', 'acpi-s5', 'secure-boot'], # } #
{ 'description': 'OVMF secboot', 'type': 'uefi' 'binary': { 'type': 'flash', 'code': { 'filename': '/usr/share/OVMF/OVMF_CODE.secboot.fd', 'format': 'raw', }, 'vars': { 'filename': '/usr/share/OVMF/OVMF_VARS.fd', 'format': 'raw', }, }, 'targets': { 'x86_64': [ "q35"], } 'features': ['acpi-s3', 'acpi-s5', 'secure-boot'], } { 'description': 'OVMF secboot enrolled', 'type': 'uefi' 'binary': { 'type': 'flash', 'code': { 'filename': '/usr/share/OVMF/OVMF_CODE.secboot.fd', 'format': 'raw', }, 'vars': { 'filename': '/usr/share/OVMF/OVMF_VARS.secboot.fd', 'format': 'raw', } }, 'targets': { 'x86_64': [ "q35"], } 'features': ['acpi-s3', 'acpi-s5', 'secure-boot', "secure-boot-enrolled-keys"], } Avoiding recording the notion of secureboot enrollment against the VARs files, means that you have more flexibility. One could just have a single file containing both CODE+VARS, which is enrolled instead of separating them. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|