On Tue, Aug 30, 2022 at 10:00 AM Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Aug 29, 2022 at 11:48:23AM +0100, Ignat Korchagin wrote: > > > > I can only elaborate here as I didn't encounter any real-world > > use-cases, but may assume some limited crypto hardware device, which > > may somehow "encourage" doing public key operations in software and > > providing only "private-key" operations due to its limited resources. > > In general if a hardware is missing a piece of the functinoality > required by the API then it should implement a software fallback. > > The only time such a NULL helper would make sense if an algorithm > had no public key. I vaguely remember some initial research in quantum-resistant signatures, which used HMAC for "signing" thus don't have any public keys. But it is way beyond my expertise to comment on the practicality and availability of such schemes. I'm more concerned here about a buggy "third-party" RSA driver, which may not implement the callback and which gets prioritised by the framework, thus giving the ability to trigger a NULL-ptr dereference from userspace via keyctl(2). I think the Crypto API framework should be a bit more robust to handle such a case, but I also understand that there are a lot of "if"s in this scenario and we can say it is up to crypto driver not to be buggy. Therefore, consider my opinion as not strong and I can post a v2, which does not provide a default stub for set_pub_key, if you prefer. Ignat
