Ferenc Rakoczi wrote: > > > Vladimir Kotal wrote: > >> Ferenc Rakoczi wrote: >> >>> Hi, Vladimir, >> >> >> Hi Ferenc, >> >>> thanks for taking care of this. >>> I have just one question: in the following places: >>> >>> kcf_cipher.c >>> >>> 389-395 >>> 685-691 >>> >>> kcf_dual.c. >>> >>> 225-244 >>> 637-652 >>> 1231-1249 >>> 1655-1669 >>> >>> kcf_mac.c >>> 158-164 >>> 296-302 >>> >>> kcf_sign.c >>> 292-298 >>> >>> kcf_verify.c >>> 294-300 >>> >>> shouldn't we retry the operation with another provider? >> >> >> I am not sure I follow. Are you suggesting that in case of grabbing >> the provider via kcf_get_mech_provider() (i.e. let the KcF scheduler >> select the "best" as opposed to grabbing it via >> kcf_get_hardware_provider()) and failing the >> kcf_check_prov_mech_keylen() check it should try to select different >> provider which would have a matching mechanism ? > > I hadn't suggested anything, it was a question. I just noticed that in > these functions if a provider returned by > kcf_get_mech_provider() turns out not to be good for some reason, they > look for the next provider. I was thinking > this without actually checking what kcf_get_mech_provider() does, so I > maybe wrong in thinking that not being able > to work with the key size is just another reason for trying some other > provider...
It's actually very good question and only now I have realized what you were asking. It makes sense to try the next provider until the list is exhausted or one which is working is found (in those functions which call kcf_get_mech_provider()). Except the above files, I have also changed kcf_callprov.c:kcf_get_dual_provider() to save the error code in the fall-back mode (just like kcf_get_mech_provider()). Incremental webrev is here: http://cr.opensolaris.org/~vkotal/kcf-keylen_check-6786946.onnv.Ferenc/ Refreshed full webrev is here: http://cr.opensolaris.org/~vkotal/kcf-keylen_check-6786946.onnv/ v.
