Re: [Qemu-devel] [virtio-dev] RE: [PATCH v18 1/2] virtio-crypto: Add virtio crypto device specification

[Halil Pasic <pasic@linux.vnet.ibm.com>]

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

2) Is a driver allowed to rejects unknown algorithm bits (e.g. give up on
the device because it considers it broken)?

If the answer is 'no' please point me to the appropriate conformance
statements.

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.

Halil