LWN: Comments on "Hardware technologies for securing containers"

Hardware technologies for securing containers

sail_darcy — Wed, 23 Mar 2016 02:51:02 +0000

Hello everyone, It's my first time to comment here. Is there any information or any projects about SGX's SDK on Linux? How can I use SGX on Linux? Any information will be very helpful, Thanks a lot.

Hardware technologies for securing containers

Cyberax — Mon, 21 Sep 2015 06:04:50 +0000

> Why would I trust that key? One way I could be sure were if I personally prepared the TPM, sealed it and then destroyed all remaining copies of the key I put in there. But now I'd have to physically ship the TPM to the data center, so it's pretty unlikely that this is how it's supposed to work.
Actually, you CAN do this - https://aws.amazon.com/cloudhsm/

But you probably want to do this:
1) Start a server.
2) Manually check that it's not compromised.
3) Create an enclave and have it generate a keypair, with the private key remaining within the sealed area.

Hardware technologies for securing containers

lsl — Mon, 21 Sep 2015 05:25:56 +0000

> Now, for people who want to rent servers in the cloud, this is all well and good.

Even then, I currently fail to see how the remote attestation stuff gives you any meaningful assurance in that case.

So, we have a key locked away in a TPM and you can only sign/decrypt stuff with it when measurement comes to the conclusion that the machine is running an unmodified copy of Yesterday's Linux (or whatever else it is that changes seldomly enough to be workable with this scheme).

Why would I trust that key? One way I could be sure were if I personally prepared the TPM, sealed it and then destroyed all remaining copies of the key I put in there. But now I'd have to physically ship the TPM to the data center, so it's pretty unlikely that this is how it's supposed to work.

How do I keep the cloud service provider from simulating a fake TPM without putting a secret in it that I know but they don't?

Hardware technologies for securing containers

mjg59 — Sun, 20 Sep 2015 19:54:42 +0000

Code in an SGX enclave has no direct access to the hardware. The only data it can download is data that the host permits it to. The only files it can access are those that the host permits it to. There's no mechanism for it to display anything or receive any input without the cooperation of the host.

Hardware technologies for securing containers

mathstuf — Sun, 20 Sep 2015 14:13:43 +0000

Hopefully, the kernel would be able to deny +x to such regions? Not that it would help if it were full of bytecode though :/ .

I think having this hooked up to some kind of permission system would be best so that I can deny the browser from using it for DRM, but allow it for, say, client cert password management. Tech like this is really going to keep pressing the bounds of DRM into lives until something breaks. Ideally, people would say "no" and do a useful boycott, but I doubt that such an easy route will be the way it goes.

Hardware technologies for securing containers

linuxrocks123 — Sun, 20 Sep 2015 05:04:26 +0000

I haven't been able to find out much about SGX, but what I have found out concerns me. It basically looks like CPU-based DRM, where user-mode code can create memory inaccessible to the CPU or even to a bus snooper that can attest to remote entities that it is what it says it is. It can then download whatever it wants from the remote entity and do whatever it wants with it, including run it. Sort of like Trusted Computing on steroids.

Now, for people who want to rent servers in the cloud, this is all well and good. For desktop users, well, we could wind up in a world where websites require your browser run in an "enclave" to prevent you from even accessing the HTML to build a scraper.

Hardware technologies for securing containers

PaXTeam — Fri, 11 Sep 2015 11:56:06 +0000

> The supervisor mode access protection (SMAP) and execution prevention (SMEP) features of some x86 processors
> are changing some of things that we learned in school about CPUs, Van de Ven said.

actually it's PaX that brought that change into the world with KERNEXEC (2003) and UDEREF (2006). SMEP (3 years old) and SMAP (<1 year old) are inadequate substitutes unfortunately as they both suffer from bad designs (e.g., SMAP ties the override capability to highly volatile processor state instead of read-only code and data).