Stefano,
I made some notes from our informal design session about adding domB
feature stuff to dom0less, and dom0less on x86
* On x86, envisaging that boot VM start materials (kernel, initrd, etc)
are loaded by multiboot, as extra blobs in the same fashion as the dom0 kernel
and initrd (and existing support for adding TXT ACMs, XSM policy file, etc)
in grub.cfg.
domB's needs:
* Need to be able to measure the boot VMs before they start
-> the measurements (or something derived from them) go into the TPM
* the measurement process needs to be tailorable to the system use case,
and doesn't need hypervisor priv; do it in a single first-booted dom0less
guest (domB).
* the first-booted guest (domB) does its measuring stuff (quickly), launches the
remaining boot guests and then exits, so it's verifiably gone,ie. along with
all privilege it was given for that work.
* as domB is starting the other boot guests, it assigns which
privileges are granted
to the domains that get started. eg. control domain, hw domain, etc.
related things:
* The TPM hardware driver doesn't live in Xen.
* Need to be able to boot the system in a way that the control domain has have
never had privilege over the domain that handles the physical TPM, or the
provider of the virtual TPM.
* The control domain can have a virtual TPM.
anyway, wanted to get this down before too much time passes so we can
get something moving
Christopher
( for ref, last year's RFC post on domB and thread: )
https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01306.html
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
