> > From: Halil Pasic [mailto:pa...@linux.vnet.ibm.com] > Sent: Friday, May 05, 2017 10:33 PM > > On 05/05/2017 07:56 AM, Gonglei (Arei) wrote: > >> > >> > >> On 05/04/2017 03:53 PM, Gonglei (Arei) wrote: > >>> Sorry, I missed one comment in the previous reply. > >>> > >>>> > >>>>> +\end{itemize*} > >>>>> + > >>>> > >>>> What about extensibility regarding "detailed algorithms"? Is the driver > >>>> required ignore algorithms > >>>> it does not "know about"? Should we reserve the not (yet) defined bits? > >>>> > >>> I mean the device MUST set the algorithms mask bits based on supported > >>> algorithms by the device, and the driver read them to get the capacity. > >>> I don't think we should care about the not defined bits. > >> > >> Let us assume that the driver fails if it encounters an unknown bit > >> (i.e. bit 13 set in hash_algo). I do not think there is anything in > >> this document that prohibits the driver doing so -- if there is please > >> do tell. Now at some point we want to support a new hash algorithm. > >> If we can't be sure that existing drivers are going to play along with > >> defining new bits (which are 'not defined bits' using your words for > >> the existing drivers) we have a small problem. > >> > >> Was I clear about my concern? > >> > > Sorry, I'm confused. For the device, it just set the bit mask based on > > supported algorithms. Please see cryptodev_builtin_init() > > in cryptodev-builtin.c, the current device only support AES_CBC algorithm, > > so we just need set: > > backend->conf.cipher_algo_l = 1u << VIRTIO_CRYPTO_CIPHER_AES_CBC; > > backend->conf.hash_algo = 1u << VIRTIO_CRYPTO_HASH_SHA1; > > > > Then the driver can only register AES CBC algorithm to the LKCF. Other > > algorithms are not supported no matter the driver if register them or not. > > > > Thanks, > > -Gonglei > > > > Now I'm confused too. So let's try to clear things up with two simple > question: > > 1) Is a device allowed to so set not defined bits ( garbage values or > even worse an implementation specific usage) way (e.g. bit 13 for > hash_algo)? > No.
> 2) Is a driver allowed to rejects unknown algorithm bits (e.g. give up on > the device because it considers it broken)? > No. The driver doesn't need to rejects, it just need care about the known algorithms. > If the answer is 'no' please point me to the appropriate conformance > statements. > OK, let's add the conformance statements in the next version. > Question 1) is about why should we reserve the remaining > bits for future use. > > Question 2) is about the interaction with feature bits -- if the answer > is 'yes' then we have to guard new algorithms with feature bits. > Thanks for explanation, I get your point until now :) Thanks, -Gonglei
