On Wed, May 19, 2021, Andy Lutomirski wrote: > On 5/18/21 10:52 AM, Sean Christopherson wrote: > > On Tue, May 18, 2021, Andy Lutomirski wrote: > >> On 5/17/21 11:21 AM, Bae, Chang Seok wrote: > >>> First of all, there is an RFC series for KVM [2]. > >>> > >>> Each CPU has one internal key state so it needs to reload it between guest and > >>> host if both are enabled. The proposed approach enables it exclusively; expose > >>> it to guests only when disabled in a host. Then, I guess a guest may enable it. > >> > >> I read that series. This is not a good solution. > >> > >> I can think of at least a few reasonable ways that a host and a guest > >> can cooperate to, potentially, make KL useful. > >> > >> a) Host knows that the guest will never migrate, and guest delegates > >> IWKEY management to the host. The host generates a random key and does > >> not permit the guest to use LOADIWKEY. The guest shares the random key > >> with the host. Of course, this means that a host key handle that leaks > >> to a guest can be used within the guest. > > > > If the guest and host share a random key, then they also share the key handle. > > And that handle+key would also need to be shared across all guests. I doubt this > > option is acceptable on the security front. > > > > Indeed. Oddly, SGX has the exact same problem for any scenario in which > SGX is used for HSM-like functionality, and people still use SGX. The entire PRM/EPC shares a single key, but SGX doesn't rely on encryption to isolate enclaves from other software, including other enclaves. E.g. Intel could ship a CPU with the EPC backed entirely by on-die cache and avoid hardware encryption entirely. > However, I suspect that there will be use cases in which exactly one VM > is permitted to use KL. Qubes might want that (any Qubes people around?)
