First of all, my apologies for the delay. I wish now with v2 [1] is a
momentum. 

On Dec 17, 2020, at 12:54, Andy Lutomirski [off-list ref] wrote:

What does this patch *do*?

It adds a new AES implementation that can be a replacement for the AES-NI
version.

IKL gives a few special key slots that have certain restrictions and
certain security properties.  

I think this can be viewed as one implementation of Envelope Encryption.
Internal Wrapping Key (IWKey) on the spec is practically Key-Encryption Key.
Each CPU has one key state and it is used to encode AES keys (or Data
Encryption Key) as many as a user wants. An encoded form may convey access
restrictions.

What can you use them for?  With this series installed, what is the
user-visible effect?  Is there a new API?  Do you use them with the netlink
user crypto interface?  Do you use them for encrypting disks?  Swap?  

No new API is added here.

No observable effect is expected to end-users. AES Key Locker provides the
same function of transforming data and does this for the chaining modes at the
same speed (or a bit faster).

As a replacement for AES-NI, the usage will be pretty much the same as
AES-NI’s. Admittedly, this instruction set has some limitations, e.g., with no
192-bit key support.

Since it can protect AES keys during the transformation, I think one may
consider using it for huge data. So, yes, block disk encryption for instance.
For testing purposes though, I was able to run it with dm-crypt [2].

How?  How do you allocate, reset, and free keys?  Who has permissions to use
them?

IWKey (or KEK) is loaded only in kernel mode. The value is randomized.

FWIW, the code intentionally sets a restriction to the encoded form. Once
encoded from an AES key, AES instructions that referencing it have to be
executed in kernel mode.

Thanks,
Chang

[1] https://lore.kernel.org/lkml/20210514201508.27967-1-chang.seok.bae@intel.com/ (local)
[2] https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMCrypt