On Fri, May 6, 2016 at 4:23 AM, Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote: > On Wed, Apr 27, 2016 at 10:18:05AM +0200, Ingo Molnar wrote: >> >> * Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> >> > > What new syscalls would be needed for ssh to get all this support? >> > >> > This patchset or similar, plus some user code and an enclave to use. >> > >> > Sadly, on current CPUs, you also need Intel to bless the enclave. It looks like >> > new CPUs might relax that requirement. >> >> That looks like a fundamental technical limitation in my book - to an open source >> user this is essentially a very similar capability as tboot: it only allows the >> execution of externally blessed static binary blobs... >> >> I don't think we can merge any of this upstream until it's clear that the hardware >> owner running open-source user-space can also freely define/start his own secure >> enclaves without having to sign the enclave with any external party. I.e. >> self-signed enclaves should be fundamentally supported as well. > > Post Skylake we will have a set of MSRs for defining your own root of > trust: IA32_SGXLEPUBKEYHASH. > > Andy had a concern that you could set root of trust multiple times, > which could lead to potential attack scenarios. These MSRs are one-shot. > ENCLS will fail if the launch control is locked. There's no possiblity > to have a root of trust that is unlocked. If this is actually true, can you ask the architecture folks to clarify their manual. The MSR description in table 35-2 says "Write permitted if CPUID.(EAX=12H,ECX=0H): EAX[0]=1 && IA32_FEATURE_CONTROL[17] = 1 && IA32_FEATURE_CONTROL[0] = 1" 39.1.4 says "If IA32_FEATURE_CONTROL is locked with bit 17 set, IA32_SGXLEPUBKEYHASH MSRs are reconfigurable (writeable). If either IA32_FEATURE_CONTROL is not locked or bit 17 is clear, the MSRs are read only. By leaving these MSRs writable, system SW or a VMM can support a plurality of Launch Enclaves for hosting multiple execution environments." This does not sound like one-shot to me. It sounds quite clear, in fact, that it's *not* one-shot so a "plurality" of these things are supported. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html