On Tue, 30 Apr 2019 10:27:28 +0200 Greg Kroah-Hartman <[email protected]> wrote:
> On Mon, Apr 29, 2019 at 11:47:52PM +0200, Marek Behun wrote: > > Hi Greg and Tejun, > > > > is it acceptable for a driver to expose sysfs attr files for ECDSA > > signature generation? > > What is "ECDSA signature generation"? Is it a crypto thing? If so, why > not use the crypto api? If not, what exactly is it? Hi Greg, It is a crypto thing and it should be accessed via akcipher crypto API. But akcipher userspace crypto API is not implemented in kernel. See below. > > The thing is that > > 1. AFAIK there isn't another API for userspace to do this. > > There were attempts in 2015 to expose akcipher via netlink to > > userspace, but the patchseries were not accepted. > > Pointers to that patchset? Why was it not accepted? Here are the replies to the last attempt https://marc.info/?t=150234726200004&r=1&w=2 This was back in 2017, apparently there were some problems and it was not merged even after 8 versions. > > 2. even if it was possible, that specific device for which I am > > writing this driver does not provide the ability to set the > > private key to sign with - the private key is just burned during > > manufacturing and cannot be read, only signed with. > > Why does this matter? If it was implemented via akcipher, the user would be unable to set private key, which is a method the akcipher implementation should implement. But this probably is not that big a problem. > > The current version of my driver exposes do_sign file in > > /sys/firmware/turris_mox directory. > > > > Userspace should write message to sign and then can read the signature > > from this do_sign file. > > How big are messages and signatures? Why does this have to be a sysfs > api? Messages are 521 bits, I rounded them to 68 bytes. The idea is that a sha512 hash of the original message is to be signed. Signatures are 136 bytes. > > According to the one attr = one file principle, it would be better to > > have two files: ecdsa_msg_to_sign (write-only) and ecdsa_signature > > (read-only). > > Would this be acceptable in the kernel for this driver? > > Why not use the crypto api, and if that doesn't work, why not just a > char device to read/write? Because the akcipher userspace crypto API is not merged and it probably will take a lot of time, if it ever will be merged. Till then I would like if this feature was supported on this one device somehow in mainline kernel. As soon as akcipher userspace crypto API is merged, I can rewrite the driver. A char device to read/write would be possible. The sysfs API seemed more strainthforward. Should I do the char device approach instead? > > I have also another question, if you would not mind: > > > > This driver is dependant on a mailbox driver I have also written > > ("mailbox: Add support for Armada 37xx rWTM mailbox"), but I have not > > received any review for this driver from the mailbox subsystem > > maintainer, and I have already sent three versions (on 12/17/2018, > > 03/01/2019 and 03/15/2019). > > What should I do in this case? > > Poke the maintainer again :) I will, Thanks. Marek
