On Apr 27, 2016 1:18 AM, "Ingo Molnar" <mingo@xxxxxxxxxx> 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. Certainly, if this were a *graphics* driver, airlied would refuse to merge it without open source userspace available. We're all used to Intel sending patches that no one outside Intel can test without because no one has the hardware. Heck, I recently sent a vdso patch that *I* can't test. But in this case I have the hardware and there is no way that I can test it, and I don't like this at all. See my earlier comments about not allowing user code to provide EINITTOKEN. Implementing that would mostly solve this problem, with the big caveat that it may be impossible to implement that suggestion until Intel changes its stance (which is clearly in progress, given the recent SDM updates). This could easily end up bring a CNL-only feature in Linux. (Or whatever generation that change is in.) --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
