sysfs attrs for HW ECDSA signature

sysfs attrs for HW ECDSA signature

[Marek Behun]

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

Re: sysfs attrs for HW ECDSA signature

[Greg Kroah-Hartman]

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

Re: sysfs attrs for HW ECDSA signature

[Marek Behun]

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

Re: sysfs attrs for HW ECDSA signature

[Greg Kroah-Hartman]

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