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