[meta-virtualization] [PATCH 0/7] Xen vTPM stubdomains

[Christopher Clark]

On Thu, Mar 8, 2018 at 12:58 PM, Bruce Ashfield <bruce.ashfield at gmail.com>
wrote:

> On Mon, Mar 5, 2018 at 10:35 AM, Kurt Bodiker
> <kurt.bodiker at braintrust-us.com> wrote:
> > This patchset introduces the basic recipes necessary to build Xen
> > stubdomains, in particular the vTPM and vTPM Manager stubdomains. vTPM
> > stubdomains provide Xen guest domains access to a virtualized TPM. The
> > vTPM Manager stubdomain manages each of the vTPM domains and seals them
> > to the physical TPM. The intention of this patchset is to provide the
> > ability to build Xen stubdomains separately from the rest of the Xen
> > components since the stubdomains have separate dependencies that are
> > hard-coded within the Xen build and configuration files.  Separating the
> > stubdomain recipes and dependencies from the rest of the Xen build gives
> > the ability to use newer or different libraries than what is currently
> > used.
> >
> > The stubdom.inc file defines a set of CPPFLAGS, CFLAGS, and LDFLAGS
> > common for building all Xen stubdomains. Xen stubdomains are
> > cross-compiled with the MiniOS, which creates some issues when trying to
> > compile stubdomains in an OpenEmbedded environment. To address these
> > issues and to ensure the stubdoms are built as Xen had intended, all of
> > the build flags and build tools that are exported into the environment
> > by OE have been unset. Each of the new recipes introduced here then
> > implements the build flags and the tools as though the build had been
> > run in the bare-metal environment.
> >
> > Xen vTPM stubdomains have depencencies on static libraries for newlib,
> > polarssl, gmp, and tpm emulator. Xen vTPM Manager stubdomain has
> > dependencies on static libraries for newlib and polarssl.
> >
> > The newlib, polarssl, gmp, and tpm emulator recipes are constructed to
> > behave the same as a bare-metal build. These recipes are cross-compiled
> > against both the Xen and MiniOS source code.
> >
> > The xen-vtpm recipe is responsible for building and installing the vTPM
> > and vTPM Manager stubdomain images into the Xen boot directory. xen-vtpm
> > would need to be added to DISTRO_FEATURES the similar for what is done
> > for Xen.
>
> I don't have any major issues with the series, I'll wait another day
> or so to see
> if there are any comments, and will merge it after that.
>


I'm supportive of this work going into meta-virtualization.

The recipes are well-structured, clear, commented and comprehensible. The
components of the stubdom are built with individual OE recipes, which is
good, and much preferred over driving a single build with the monolithic
upstream Makefile: it will make it easier to work with the individual
recipes to upgrade component versions in a standard OE manner.

Location of recipe files:
This series introduces many recipes into recipes-extended/xen. I think that
is fair and appropriate to locate them there - they are the set of external
components and versions specified in the Xen stubdom code base, they are
built to be deployed in conjunction with the Xen binaries, and it makes
sense to co-locate them.

README:
It think it would helpful to add some introduction text to
recipes-extended/xen/README to explain that the recipes for these
components are there because they are the software specified in the
upstream Xen stubdom tree, and also include some of the text from this
series's cover letter -- in particular noting that the build for these
recipes will proceed with the host machine's compiler and build tools, not
those of OE native due to the minios cross-compile challenges.

Christopher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-virtualization/attachments/20180308/e1893c73/attachment.html>