Hi Jason, Thanks for your reply and helpful summary of the current discussion. > > 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 > sense. Yes, that's correct. There are currently no standardised APIs for HSM devices in Linux and our PCIe device needs the kernel to facilitate operation. > > 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? Yes, this 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. Again, you are correct. Although it is cryptographic hardware, the driver code does not do anything cryptographic. It is just a PCIe driver. > > 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 components? Yes, we expect there to be some discussion about the driver being useful in the kernel but need to resolve this discussion regarding the Linux crypto API first. > > 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 > responsibilities). Yes, we submitted our driver code to Greg and drivers/misc but he requested feedback from the crypto maintainers regarding potential changes to the Linux crypto API. We do not intend to target our driver submission to drivers/crypto and aren't using any of the Linux crypto APIs. Regards, Dave David Kim Senior Software Engineer Tel: +44 1223 703449 nCipher Security One Station Square Cambridge CB1 2GA United Kingdom
