On Wed, Jun 14, 2017 at 11:28:32AM +1200, Huang, Kai wrote:
On 6/14/2017 6:57 AM, Jarkko Sakkinen wrote:
> On Mon, Jun 12, 2017 at 09:53:41PM +1200, Huang, Kai wrote:
> > > > This is simple, we simply won't allow guest to choose its own
> > > > IA32_SGXLEPUBKEYHASHn by specifying 'lehash' value in Qemu
> > > > creating the guest.
> > >
> > > Why not? You could have virtual MSRs and ask host LE to generate token
> > > if they match to modulus.
> > The guest has its own LE running inside, and guest's LE will generate
> > for enclaves in guest. The host will not generate token for guest in any
> > circumstances, because this is totally guest's behavior.
> Why can't host LE generate the token without guest knowning it and
> supply it with EINIT?
I have said many times, virtualization is only about to emulate hardware
behavior. The same software runs in native machine is supposed to run in
guest. I don't care on host how you implement -- whether LE delegates token
for other enclave or not. Your implementation works on host, the exact
driver works in guest. I said several times, I even don't have to trap
EINIT, in which case you simply cannot generate token for EINIT from guest,
because there is no EINIT from guest!
> > > Seriously sounds like a stupid constraint or I'm not getting
> > > (which also might be the case). If you anyway trap EINIT, you could
> > > create a special case for guest LE.
> > This is not constraint, but KVM has to emulate hardware correctly. For this
> > part please see my explanation above.
> I'm being now totally honest to your: your explanation makes absolutely
> zero sense to me. You don't need a 1000+ words to explain the scenarios
> where "host as a delegate LE" approach would go wrong.
This doesn't require 1000+ words.. This is simple, and I have explained:
This is not constraint, but KVM has to emulate hardware correctly.
The additional 1000+ words that I spent lots of time on typing is trying to
explain to you -- why we (at least Andy, Sean, Haim I believe) agreed to
choose to trap EINIT.
> Please just pinpoint the scenarios where it goes wrong. I'll ignore
> the text below.
Of course you can, if you already understand why we agreed to choose to trap
I think Andy's comments just made things more complicated. He is trying to
solve problems that don't exist in your implementation, and I believe we can
handle this in the future, if those problems come up.
So let's focus on how to handle updating MSRs and EINIT. I believe Andy, me,
and Sean are all on the same page. Not sure whether you are or not.
For me I am perfectly fine not to trap EINIT (which is exactly this patch
did), but you have to guarantee the correctness of host side.
I'm not yet seeing why MSRs would ever would need to be updated.
See my response to Sean for details.
There's probably some detail in the SDM that I'm not observing.