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 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? > > 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 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. > > 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 > EINIT. > > 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. > > > > > /Jarkko > > 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. /Jarkko
