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 <luto@xxxxxxxxxx> 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@xxxxxxxxx/ [2] https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMCrypt
