OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


>
> From: Halil Pasic [mailto:pasic@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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]