On Tue, Jun 13, 2017 at 09:57:18PM +0300, 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 parameter when > > > > 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 token > > 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? > > > Seriously sounds like a stupid constraint or I'm not getting something > > > (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. > > Please just pinpoint the scenarios where it goes wrong. I'll ignore > the text below. > > /Jarkko When I've been reading this discussion the biggest lesson for me has been that this is a new argument for having in-kernel LE in addition to what Andy has stated before: the MSRs *never* need to be updated on behalf of the guest. /Jarkko
