4:01 p.m.
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"
as possible.
I've looked at the three different layers and feel that
meta-secure-core might
be a better one to target. With respect to its TPM2 recipes, however,
meta-secure-core (and the other, meta-security) lag behind meta-measured. As
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 could
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
After this gets reviewed and if usptream is willing I'm then hoping to
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?
Looking at the master commit of tpm2-tss, specifically, I've
noticed a number
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 libtcti-device.
But are there any mappings from the new stuff to the older libtcti-socket and
libsapi?
It looks like things are going to get messy. It looks like, going forward,
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 recipes
that use tss (and expect the old 1.x behaviour/API) can continue to work while
allowing new code (or updates to the old) to use the new API (?).
I think Bill got all of this covered in his reply.
Philip
Best regards,
Trevor
_______________________________________________
tpm2 mailing list
tpm2(a)lists.01.org
https://lists.01.org/mailman/listinfo/tpm2