On Wed, May 19, 2021, Andy Lutomirski wrote:

On 5/18/21 10:52 AM, Sean Christopherson wrote:

quoted

On Tue, May 18, 2021, Andy Lutomirski wrote:

quoted

On 5/17/21 11:21 AM, Bae, Chang Seok wrote:

quoted

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?)