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@xxxxxxxxxxxxxxxxxxx> 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