> One person's "corner case" is another person's "use case". Once you > That argument works both ways though. Someone else's use case may be getting decent performance from an accelerator for a specific application, which has worked fine for years but is now broken to comply with some (for them!) possibly irrelevant corner of the API. > register > your driver with the crypto API, you can't control how it's used. If > you > provide "cbc(aes)", for example, anyone in the kernel may get your > driver when > they ask the crypto API to do "cbc(aes)" encryption or decryption. > I understand that's how it currently works. So maybe we need some more control from the driver there, as you suggested below yourself. > Correctness comes first, and there's no such thing as "testing the > algorithm, > not the API", since the API is means by which the algorithm is > accessed. So you > *must* implement the API correctly. If you don't, it's very much > Working As > Intended for the self-tests to disable your driver. > But, lacking a formal specification, who decides what is a "correct" implementation of the API? > If you aren't happy with the API, then please work with the community > to improve > the API instead. > That's exactly the plan :-) And I'm not unhappy, by the way ;-) > E.g. perhaps we should annotate with a new request > flag all > users who may actually need the IV chaining behavior. Then on all > other > requests, implementations wouldn't be required to provide the next IV. > It would > add complexity, but perhaps it would be worthwhile. > There was another suggestion along those lines, but then inverted, like the user requesting that it does NOT need the IV chaining. I like that better as it would be fully backward compatible and you could change just the users that would actually benefit and leave everything else untouched. > Remember that in the case of unsupported lengths, keys, or data > layouts, you > also have the option of using a fallback algorithm to handle those > cases. Grep > for CRYPTO_ALG_NEED_FALLBACK to see examples in other drivers. > Yes, except that I cannot fallback because of the output IV thing if I don't know the user is going to need the output IV. I surely don't want to fallback by default! So I need that flag. Regards, Pascal
