linux-kernel - Re: [PATCH v2] drivers: misc: Add support for nCipher HSM devices

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 7 Jan 2020 10:28:27 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     "Kim, David" <david.kim@...pher.com>
Cc:     "arnd@...db.de" <arnd@...db.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Magee, Tim" <tim.magee@...pher.com>
Subject: Re: [PATCH v2] drivers: misc: Add support for nCipher HSM devices

On Tue, Jan 07, 2020 at 08:50:50AM +0000, Kim, David wrote:
> 
> > >
> > > This is the driver for nCipher’s Solo and Solo XC hardware security modules.
> > > These modules implement a proprietary command set (the ’nCore API’) to
> > > perform cryptographic operations - key generation, signature, and so
> > > on. HSM commands and their replies are passed in a serialised binary
> > > format over the PCIe bus via a shared memory region. Multiple commands
> > > may be in-flight at any one time - command processing is
> > > multi-threaded and asynchronous. A write operation may, therefore,
> > > deliver multiple commands, and multiple replies may be retrieved in one
> > read operation.
> > 
> > If this is "just" a crypto accelerator, why isn't this driver using the existing in-
> > kernel hardware crypto api?  What is lacking from it that you need here?
> 
> Hi Greg,
> 
> A cryptographic accelerator uses key material which is stored on, and managed by, the host machine. Hardware security modules, such as nCipher’s Solo products, retain key material (i.e. secrets) within the secure boundary of the device, and implement various forms of access control to restrict use of that key material.
> 
> nCipher's product range started, in the early 1990s, as cryptographic accelerators.  The series of hardware security modules served by this driver still does do cryptography but their main function is the generation, management and use of keys within a secure boundary.
> 
> The driver doesn't do any cryptography. It provides the link between the userspace software and the HSM's firmware. Cryptography is done within the HSM's secure boundary.

So this should tie into the correct crypto/key apis that the kernel has
and not create a brand new user/kernel api, right?

Please work with the crypto kernel developers to get this right, I can't
take this until they agree that this code and api is correct.

thanks,

greg k-h