lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 30 Apr 2019 12:06:40 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Marek Behun <marek.behun@....cz>
Cc:     Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: sysfs attrs for HW ECDSA signature

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@...uxfoundation.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ