archive mirror
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <>
To: "Kim, David" <>,
	Greg KH <>
Cc: "" <>,
	"" <>,
	"" <>,
	"Magee, Tim" <>,
	Arnd Bergmann <>
Subject: Re: nCipher HSM kernel driver submission feedback request
Date: Mon, 23 Mar 2020 00:49:57 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Dave,

I took a look at your driver to try to understand what's going on here 
and what the disagreement is all about.

It looks like this is some sort of PCIe HSM device. As far as I know, 
Linux doesn't have a standardized API for HSM devices (somebody correct 
me if I'm wrong), and probably that doesn't quite make sense, either, 
seeing as most HSMs are accessed anyway through userspace "drivers" -- 
that is, via libusb or over some networking protocol, or something else. 
Your situation is different in that it uses PCIe, so you need some 
kernel mediation in order to give access to your userspace components. 
And, different manufacturers' HSMs expose very different pieces of 
functionality, and I'm not sure a unified API for them would even make 

It looks like this driver exposes some device file, with a few IOCTLs 
and then support for reading and writing from and to the device. Besides 
some driver control things, what actually goes into the device -- that 
is, the protocol one must use to talk to the thing -- isn't actually 
described by the driver. You're just shuffling bytes in and out with 
some mediation around that.

Can you confirm to me whether or not the above is accurate?

If so, then I'm not sure this belongs in the purview of the crypto list 
or has anything much to do with Linux crypto. This is a PCIe driver for 
some hardware that userspace has to talk to in order to do some stuff 
with it.

However, there's something else that you wrote that might make people 
less inclined to merge this:

 > Our driver code is just a tube between proprietary code on the host 
machine and proprietary code on the HSM.

It sounds like you need the kernel to expose your PCIe device in a way 
userspace can access, so that you can talk to it using proprietary code. 
In other words, this is a kernel driver that exists only to support 
closed source components. I have no idea about "official policy" on this 
matter, but I could imagine some people howling about it. On the other 
hand, the driver _is_ doing something, and it seems like your hardware 
is somewhat complicated to interface with, and who wouldn't want an open 
source driver for that, even if it's just the low-level kernel/PCIe 

Anyway, if my suppositions above are indeed correct, I'd encourage you 
to submit your driver to whoever maintains drivers/misc/ (Greg and Arnd, 
IIRC), and ignore the fact that your hardware has something to do with 
cryptography (though little to do with the Linux crypto API's range of 


  parent reply	other threads:[~2020-03-23  6:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-13  9:48 Kim, David
2020-03-13 10:09 ` Greg KH
2020-03-16 10:44   ` Kim, David
2020-03-16 11:23     ` Greg KH
2020-03-23  6:49 ` Jason A. Donenfeld [this message]
2020-03-23 13:32   ` Kim, David
2020-03-23 13:59     ` Greg KH
2020-04-17 15:12       ` Kim, David

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='Re: nCipher HSM kernel driver submission feedback request' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).