On Fri, Jun 1, 2018 at 7:01 PM, Philip Tricca <philip.b.tricca(a)intel.com>
On Wed, May 30, 2018 at 05:13:04PM -0400, Trevor Woerner wrote:
> Hi Philip,
> My hope is that one day the OE community will have one security layer to
> choose, rather than the three that we have currently.
In my experience things that live in a separate "security" area rarely
get tested well. Ideally they would live as close to the upstream "core"
If enough people can be convinced that this needs to be in core that it
ends up there one day, that would be awesome! But my gut feeling is that
there isn't quite enough interest just yet for all this security stuff to
not be in its own layer.
> I've looked at the three different layers and feel that
> be a better one to target. With respect to its TPM2 recipes, however,
> meta-secure-core (and the other, meta-security) lag behind
> such I've been working on some updates for meta-secure-core.
> Are you still keen to fold meta-measured into something else? If not I
> prepare a set of patches for meta-measured as well.
Given the above my first priority is figuring out how far upstream the
various pieces can go. I've been chatting with a few folks and have been
working up patches to yocto-kernel-cache and openembedded-core to
cleanup the kernel config fragments and integrate the resulting
kernel-module packages into packagegroup-base. With the swtpm stuff
being integrated into qemu it's now possible to test at least the
tpm-tis driver by:
1) creating a qemu machine with 'tpm-tis' added to the MACHINE_FEATURES
2) setup the swtpm daemon
3) runqemu booting core-image-base to verity the /dev/tpm* is created
I wasn't aware that the latest qemu had support for TPM; this is great
news! I've heard that the latest qemu also has raspberrypi emulation
support, that's something else I should investigate as well :-)
After this gets reviewed and if usptream is willing I'm then
propose moving the recipes for user space bits as close to
openembedded-core as possible. I think the ideal end state would be
enabling something via COMBINED_FEATURES so that we can have
MACHINE_FEATURES and DISTRO_FEATURES working together to seamlessly pull
in the right kernel driver and TSS(2)? recipes.
Something you're willing to help test and maybe contribute a 'tested-by'
tag on patches when they get sent upstream?
Absolutely! (although I might need an individual, side-channel ping to
alert me to their addition since I can't follow the various OE patch lists
in detail every day)
Currently meta-measured has one kernel option that isn't RPi-friendly. I
never said anything about it since it was easy enough to remove through
local configurations. Therefore I'm looking forward to these new fragments
to see how they'll do on non-Intel hardware.
In any case, I could imaging the kernel fragments *might* make it into
oe-core, but I doubt something like the TPM2 recipes would. Those will
probably need to find a home outside oe-core.
> Looking at the master commit of tpm2-tss, specifically, I've
> of changes and was hoping for your feedback.
> With the tss 1.x stuff we had:
> - libtcti-device
> - libtcti-socket
> - libsapi
> The new tss 2.x stuff has:
> - libtss2-esys
> - libtss2-mu
> - libtss2-sys
> - libtss2-tcti-device
> - libtss2-tcti-mssim
> I'm guessing libtss2-tcti-device is the new name for the old
> But are there any mappings from the new stuff to the older
> It looks like things are going to get messy. It looks like, going
> we're going to need to keep tpm2-tss_1.x.bb around as well as create
> tpm2-tss_2.x.bb recipes with differently named PACKAGES so existing
> that use tss (and expect the old 1.x behaviour/API) can continue to work
> allowing new code (or updates to the old) to use the new API (?).
I think Bill got all of this covered in his reply.
Yes, and he did an excellent job; thank you!
PS: how was the security summit?