James Bottomley: Containers and Cloud Security

The idea behind this blog post is to take a new look at how cloud security is measured and what its impact is on the various actors in the cloud ecosystem. From the measurement point of view, we look at the vertical stack: all code that is traversed to provide a service all the way from input web request to database update to output response potentially contains bugs; the bug density is variable for the different components but the more code you traverse the higher your chance of exposure to exploitable vulnerabilities.[…]



TPM microconf at 2017 Linux Plumbers Conference

Matthew Garrett has announced a TPM microconference at the upcoming Linux Plumbers Conference:

I’m pleased to say that after the success last year, there will be another TPM microconference at this year’s Linux Plumbers Conference. The current schedule has this taking place on Wednesday the 13th of September, so just under 4 weeks from now. We have a list of proposals for discussion at http://wiki.linuxplumbersconf.org/2017:tpms but please feel free to add more! I intend to finalise the schedule by the end of next week, so please do so as soon as you can. For those of you who weren’t there, the Linux Plumbers conference is an event dedicated to bringing together people working on various infrastructural components (the plumbing) of Linux. Microconferences are 3 hour long events dedicated to a specific topic, with the focus on identifying problems and having enough people in the room to start figuring out what the solutions should be – the format is typically some short presentations coupled with discussion.

From James Bottomley’s comments on the LPC entry on this microconf:

Following on from the TPM Microconference last year, we’re pleased to announce there will be a follow on at Plumbers in Los Angeles this year. The agenda for this year will focus on a renewed attempt to unify the 2.0 TSS; cryptosystem integration to make TPMs just work for the average user; the current state of measured boot and where we’re going; using TXT with TPM in Linux and using TPM from containers.



Full text of Matthew’s email:

James on Linux and TPM (and TouSerS)

James Bottomley has a new blog post on TPM v2 and Linux:


See his pervious blog posts for more on TPM and Linux.

Blogging aside, James also posted a TPM2 patch to TouSerS to allow support for OpenSSL:

[TrouSerS-tech] [PATCH 0/1] TPM2 engine support for openssl

This is a completed version of the original RFC.  It’s working now both on the TPM2 simulator and on real hardware (I’ve converted my laptop to TPM2).  I’ve updated it to use the latest version of the ASN.1 for the key format (still using a TCG OID). I have it building here (it’s what I’m currently using for my laptop VPNs):


But note that this version also has experimental patches to activate the in-kernel TPM Resource Manager because for multiple applications TPM2 really doesn’t work well without one.  Since the patch for the RM is currently not upstream (yet), it’s not going to work unless you have a patched kernel.

More info:

James on Linux TPM stack

James has a new blog post that gives a good introduction to the Linux TPM stack:

“[…]One of the great advantages of the TPM, instead of messing about with USB pkcs11 tokens, is that it has a file format for TPM keys (I’ll explain this later) which can be used directly in place of standard private key files.  However, before we get there, lets discuss some of the basics of how your TPM works and how to make use of it.[…]”



efitools now available for ARM

James Bottomley has a few new blog posts, two on efitools availability for ARM, and another on a container model for UEFI.


Constructing Architecture Emulation Containers

[…] the problem: how to build and test efitools for arm and aarch64 while not possessing any physical hardware.  The solution is to build an architecture emulation container using qemu and mount namespaces such that when its entered you find yourself in your home directory but with the rest of Linux running natively (well emulated natively via qemu) as a new architecture.  […] However, there’s a problem here: the installed binary emulator usually runs as /usr/bin/qemu-${arch}, so if you’re running a full operating system container, you can’t install any package that would overwrite that.  Unfortunately for me, the openSUSE Build Service package osc requires qemu-linux-user and would cause the overwrite of the emulator and the failure of the container.  The solution to this was to bind mount the required emulator into the / directory, where it wouldn’t be overwritten and to adjust the binfmt_misc paths accordingly. […]