Hi Stephan, Keyrings is in-kernel key-management and retention facility. User can use it to manage keys used for applications. Xilinx cryptographic hardware has a mechanism to store keys in its internal hardware and do not have mechanism to read it back due to security reasons. It stores key internally in different forms like simple key, key encrypted with unique hardware DNA, key encrypted with hardware family key, key stored in eFUSEs/BBRAM etc. Based on security level expected, user can select one of the key for AES operation. Since AES hardware internally has access to these keys, user do not require to provide key to hardware, but need to tell which internal hardware key user application like to use for AES operation. Basic need is to pass information to AES hardware about which internal hardware key to be used for AES operation. I agree that from general use case perspective we are not selecting key type but selecting internal hardware keys provided by user. How about providing option to select custom hardware keys provided by hardware (AES_SEL_HW_KEY)? Thanks kalyani > -----Original Message----- > From: Stephan Mueller <smueller@xxxxxxxxxx> > Sent: Thursday, April 25, 2019 12:01 AM > To: Kalyani Akula <kalyania@xxxxxxxxxx> > Cc: herbert@xxxxxxxxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; linux- > crypto@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx > Subject: Re: [RFC PATCH 4/5] crypto: Adds user space interface for > ALG_SET_KEY_TYPE > > Am Montag, 22. April 2019, 11:17:55 CEST schrieb Kalyani Akula: > > Hi Kalyani, > > > > Besides, seem to be more a key handling issue. Wouldn't it make > > > sense to rather have such issue solved with key rings than in the > > > kernel crypto API? > > > > [kalyani] Can you please elaborate on this further ? > > The kernel has a keyring support in security/keys which has a user space > interface with keyutils. That interface is commonly used for any sort of key > manipulation. > > Ciao > Stephan >
