* sysfs attrs for HW ECDSA signature
@ 2019-04-29 21:47 Marek Behun
2019-04-30 8:27 ` Greg Kroah-Hartman
0 siblings, 1 reply; 4+ messages in thread
From: Marek Behun @ 2019-04-29 21:47 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Tejun Heo, linux-kernel
Hi Greg and Tejun,
is it acceptable for a driver to expose sysfs attr files for ECDSA
signature generation?
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.
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.
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.
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?
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?
Thank you.
Marek
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: sysfs attrs for HW ECDSA signature 2019-04-29 21:47 sysfs attrs for HW ECDSA signature Marek Behun @ 2019-04-30 8:27 ` Greg Kroah-Hartman 2019-04-30 9:23 ` Marek Behun 0 siblings, 1 reply; 4+ messages in thread From: Greg Kroah-Hartman @ 2019-04-30 8:27 UTC (permalink / raw) To: Marek Behun; +Cc: Tejun Heo, linux-kernel 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? > 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? > 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? > 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? > 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? > 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 :) thanks, greg k-h ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: sysfs attrs for HW ECDSA signature 2019-04-30 8:27 ` Greg Kroah-Hartman @ 2019-04-30 9:23 ` Marek Behun 2019-04-30 10:06 ` Greg Kroah-Hartman 0 siblings, 1 reply; 4+ messages in thread From: Marek Behun @ 2019-04-30 9:23 UTC (permalink / raw) To: Greg Kroah-Hartman; +Cc: Tejun Heo, linux-kernel On Tue, 30 Apr 2019 10:27:28 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: sysfs attrs for HW ECDSA signature 2019-04-30 9:23 ` Marek Behun @ 2019-04-30 10:06 ` Greg Kroah-Hartman 0 siblings, 0 replies; 4+ messages in thread From: Greg Kroah-Hartman @ 2019-04-30 10:06 UTC (permalink / raw) To: Marek Behun; +Cc: Tejun Heo, linux-kernel On Tue, Apr 30, 2019 at 11:23:19AM +0200, Marek Behun wrote: > On Tue, 30 Apr 2019 10:27:28 +0200 > Greg Kroah-Hartman <gregkh@linuxfoundation.org> 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. Great, get the akcipher code merged then, that should solve your problem. > > > 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. No, do not try to route-around the proper api being present and hack up something on your own, that way lies madness and you will then have to support two apis for the hardware if your char driver is accepted. Just work on the akcipher code to get that cleaned up properly and merged, along with your driver that uses it, and all should be fine. good luck! greg k-h ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-04-30 10:06 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-04-29 21:47 sysfs attrs for HW ECDSA signature Marek Behun 2019-04-30 8:27 ` Greg Kroah-Hartman 2019-04-30 9:23 ` Marek Behun 2019-04-30 10:06 ` Greg Kroah-Hartman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).