nCipher HSM kernel driver submission feedback request

nCipher HSM kernel driver submission feedback request

[Kim, David]

Hi Herbert,

We've been working on getting this driver code upstreamed into drivers/misc since the end of last
year but things stalled a bit on our end. However, we are still interested in getting our submission
approved and would please like your assistance and feedback on this.

The driver code for the hardware is straightforward and does not contain any cryptographic
components as the cryptography is handled within the hardware's secure boundary. We have no
plans to use the linux kernel crypto APIs as our customers require compliance to the FIPS 140
standard or the eIDAS regulations.

Here is a link to the previous email I sent, which also contains more background links to our initial
discussions with Greg and the actual patch.

https://marc.info/?l=linux-crypto-vger&m=157918288423889&w=2

Can I please have your approval on this submission?

Thanks,
Dave


David Kim
Senior Software Engineer
Tel: +44 1223 703449

nCipher Security
One Station Square
Cambridge CB1 2GA
United Kingdom

Re: nCipher HSM kernel driver submission feedback request

[Greg KH]

On Fri, Mar 13, 2020 at 09:48:14AM +0000, Kim, David wrote:
> Hi Herbert,
> 
> We've been working on getting this driver code upstreamed into drivers/misc since the end of last
> year but things stalled a bit on our end. However, we are still interested in getting our submission
> approved and would please like your assistance and feedback on this.
> 
> The driver code for the hardware is straightforward and does not contain any cryptographic
> components as the cryptography is handled within the hardware's secure boundary. We have no
> plans to use the linux kernel crypto APIs as our customers require compliance to the FIPS 140
> standard or the eIDAS regulations.

But what I said was, you NEED to use the linux kernel crypto apis as you
need to not try to create your own.

Just because this is the way you did it before, does not mean it is the
correct thing to do.

So what is wrong if you do use the existing apis?  What is preventing
you from doing that?

thanks,

greg k-h

RE: nCipher HSM kernel driver submission feedback request

[Kim, David]

> > The driver code for the hardware is straightforward and does not
> > contain any cryptographic components as the cryptography is handled
> > within the hardware's secure boundary. We have no plans to use the
> > linux kernel crypto APIs as our customers require compliance to the FIPS
> 140 standard or the eIDAS regulations.
>
> But what I said was, you NEED to use the linux kernel crypto apis as you need
> to not try to create your own.
>
> Just because this is the way you did it before, does not mean it is the correct
> thing to do.
>
> So what is wrong if you do use the existing apis?  What is preventing you
> from doing that?
>

Sorry Greg but I'm not understanding what the issue is. Can you please explain a
bit more what you mean with the apis?

Our driver code is just a tube between proprietary code on the host machine and
proprietary code on the HSM. We are not trying to create our own linux crypto
apis because all the crypto stuff is happening in the existing proprietary code.

Regards,
Dave


David Kim
Senior Software Engineer
Tel: +44 1223 703449

nCipher Security
One Station Square
Cambridge CB1 2GA
United Kingdom

Re: nCipher HSM kernel driver submission feedback request

[Greg KH]

On Mon, Mar 16, 2020 at 10:44:46AM +0000, Kim, David wrote:
> 
> > > The driver code for the hardware is straightforward and does not
> > > contain any cryptographic components as the cryptography is handled
> > > within the hardware's secure boundary. We have no plans to use the
> > > linux kernel crypto APIs as our customers require compliance to the FIPS
> > 140 standard or the eIDAS regulations.
> > 
> > But what I said was, you NEED to use the linux kernel crypto apis as you need
> > to not try to create your own.
> > 
> > Just because this is the way you did it before, does not mean it is the correct
> > thing to do.
> > 
> > So what is wrong if you do use the existing apis?  What is preventing you
> > from doing that?
> > 
> 
> Sorry Greg but I'm not understanding what the issue is. Can you please explain a
> bit more what you mean with the apis?
> 
> Our driver code is just a tube between proprietary code on the host machine and
> proprietary code on the HSM. We are not trying to create our own linux crypto
> apis because all the crypto stuff is happening in the existing proprietary code.

If your device does "crypto", then it should tie into the existing
kernel crypto apis so that your, and everyone elses, userspace code also
uses the correct, existing, userspace crypto apis.

We do not want to create a one-off-vendor-specific api for only one
piece of hardware out there.  That way lies madness and is not how we do
things in the kernel whenever possible.

thanks,

greg k-h

Re: nCipher HSM kernel driver submission feedback request

[Jason A. Donenfeld]

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

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 
components?

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

Jason

RE: nCipher HSM kernel driver submission feedback request

[Kim, David]

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

Re: nCipher HSM kernel driver submission feedback request

[Greg KH]

On Mon, Mar 23, 2020 at 01:32:06PM +0000, Kim, David wrote:
> 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.

If this is "just" a PCIe driver, can you use the UIO interface and just
talk to your hardware directly from userspace without any kernel driver
needed?

What exactly does the kernel driver need to do here?

thanks,

greg k-h

RE: nCipher HSM kernel driver submission feedback request

[Kim, David]

> > Again, you are correct. Although it is cryptographic hardware, the
> > driver code does not do anything cryptographic. It is just a PCIe driver.
>
> If this is "just" a PCIe driver, can you use the UIO interface and just talk to
> your hardware directly from userspace without any kernel driver needed?
>
> What exactly does the kernel driver need to do here?
>

Hi Greg,

Apologies for the delay in response but things took a little bit to get to some
kind of new normal. Hope things are well for you.

We would need to re-write our driver code in order to use the UIO interface
and access the hardware directly from userspace.  Besides the actual work
involved, this would add extra complexity to our code base as we support
other operating systems, which we would not be re-writing our drivers for.
Therefore, writing a userspace driver is not something we are planning to do
at this time.

We have worked through all the submission guides and have made our existing
driver 'submission ready' as best we can. This is the code we would like to be
considered for upstreaming. Should we make it into the linux codebase, we are
committed to providing long term community support for it.

Regards,
Dave


David Kim
Senior Software Engineer
Tel: +44 1223 703449

nCipher Security
One Station Square
Cambridge CB1 2GA
United Kingdom