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
