Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

On Mon, May 14, 2018 at 3:08 PM, Jason Gunthorpe <j...@ziepe.ca> wrote:
> On Mon, May 14, 2018 at 02:59:36PM -0500, David R. Bild wrote:
>> On Mon, May 14, 2018 at 2:31 PM, Jason Gunthorpe <j...@ziepe.ca> wrote:
 The driver can setup enough to use the TPM
>> > framework to send commands before completing registration. We use it
>> > in startup timeouts and other flows today.
>>
>>
>> That sounds perfect.  Can you point me to some usages in the code (or
>> relevant functions)?
>>
>
> Well, tpm_tis_core_init() does it
>
> Only the driver that calls tpm_chip_register() gets to use this
> capability, so you can't use "tpm_tis_spi" and the automatic binding
> if you need it.
>
> Looks like the spi binding and tpm_tis_core_init will need some gentle
> editing to allow a SPI based driver the same opportunity.

Thanks for the pointers.  I'll work with Peter to add this capability
for SPI drivers.

Best,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

On Mon, May 14, 2018 at 2:31 PM, Jason Gunthorpe <j...@ziepe.ca> wrote:
>
> On Thu, May 10, 2018 at 09:41:53AM -0500, David R. Bild wrote:
>
> > 3) Allow the driver to register the TPM with TPM driver, but not yet
> > expose the TPM to userspace.  Let the driver do some additional work
> > (like set the platform hierarchy password) and then explicitly inform
> > the TPM driver that it is safe to expose the TPM to userspace.  This
> > would be my preferred approach.
>
> We already have this. The driver can setup enough to use the TPM
> framework to send commands before completing registration. We use it
> in startup timeouts and other flows today.


That sounds perfect.  Can you point me to some usages in the code (or
relevant functions)?

This driver registers with the TPM subsystem using the "tpm_tis_spi"
driver like this:

"
  static struct spi_board_info tpm_board_info = {
  .modalias   = "tpm_tis_spi",
  .max_speed_hz = 43 * 1000 * 1000, // Hz
  .chip_select   = 0,
  .mode= SPI_MODE_0
  };

  struct spi_device *tpm = spi_new_device(spi_master, _board_info);
"

I don't see how sending of commands before completing registration.
At the very least, the "tpm_tis_spi" driver probably has to be
changed?

Best,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

On Thu, May 10, 2018 at 9:47 AM, James Bottomley
<james.bottom...@hansenpartnership.com> wrote:
> On Thu, 2018-05-10 at 09:25 -0500, David R. Bild wrote:
>> The TPM holds access credentials for connecting to the Xaptum
>> network.
>
> OK, so these are effectively DevId keys.  However, what makes you think
> knowing the platform auth allows you to duplicate the keys?

It doesn't and we don't think that.

> As long as
> you created them correctly (as in without duplication authority) then
> even knowing the platform authorization I can't get them out of your
> TPM.

Correct.  No one can copy/duplicate/read them.

But they can delete them, which is effectively a denial of service
attack against the device.

>> We provision the credentials (the DAA secret key, specifically) under
>> the platform hierarchy. The key can be used without platform
>> authorization, but not removed.  If we disable the platform hierarchy
>> entirely, I think the credentials will no longer be available for
>> use.
>
> That's certainly true if you actually need to use the platform
> hierarchy.  Your initial emails on the subject did say you were
> disabling it though ...

Mea culpa.  Lazy wording on my part.

>> > Early boot means userspace. for a hot pluggable device, this would
>> > probably be something in udev if you follow the no-daemon model and
>> > the daemon could do it if you do follow the daemon model.
>>
>> Could you expand on the udev approach?  I might not understand enough
>> about udev (or the coming TPM resource manager changes) to follow the
>> suggestion.

>> This seems unsafe to me.  There's a race between a malicious
>> userspace program and the daemon to set the platform
>> authorization.  If the malicious program wins, it can reset the TPM,
>> removing the credentials, and the device won't be able to connect to
>> the Xaptum network. (This is a liveness concern, not safety.  A
>> denial-of-service attack, essentially.)
>
> OK, I'm getting confused by your threat model.  I don't think knowing
> the platform auth I can obtain your keys.  However, I agree, I can
> definitely remove them.

Correct. Removal (not copying) is our concern.

>  However, setting platform auth doesn't solve
> this: I can execute a TPM2_Clear to regain the platform auth and if you
> disable this

According to the spec (v1.38) TPM2_Clear

- flushes the Storage and Endorsement hierarchies, not the Platform hierarchy.

- resets the Storage, Endorsement, and Lockout auth, but not the Platform auth.

> I can't re-own the TPM at all.

You can execute TPM2_Clear  (if you have lockout auth. We don't set
lockout auth, so you will.) to regain control of the Storage and
Endorsement hierarchies.  We only control the platform hierarchy.

Best,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

On Tue, May 8, 2018 at 5:55 AM, Jarkko Sakkinen
<jarkko.sakki...@linux.intel.com> wrote:
> On Fri, May 04, 2018 at 02:56:25PM -0500, David R. Bild wrote:
>> On Fri, May 4, 2018 at 2:06 PM, Jason Gunthorpe <j...@ziepe.ca> wrote:
>> >
>> > On Fri, May 04, 2018 at 08:00:22AM -0500, David R. Bild wrote:
>> > > Normally the system platform (i.e., BIOS/UEFI for x86) is responsible
>> > > for performing initialization of the TPM.  For these modules, the host
>> > > kernel is the platform, so we perform the initialization in the driver
>> > > before registering the TPM with the kernel TPM subsystem.
>> >
>> > The tpm driver already does most of this stuff automatically, why
>> > duplicate it there and why is it coded in a way that doesn't use the
>> > existing TPM services to do it?
>>
>> I didn't want to have to duplicate all that functionality and was
>> disappointed when that became the only option (due to the two reasons
>> outlined below) for supporting existing kernels with an out-of-tree
>> module.
>>
>> Bringing the module in-tree opens the option of reworking some of the
>> TPM subsystem to support this use case.  I'm open to concrete
>> suggestions on how to do so.
>>
>> 1) The first reason is that I don't think the necessary pieces are
>> currently made available for reuse. I'd love to not repeat that code,
>> but
>>
>> - some required structs and functions are declared in private headers
>> (drivers/char/tpm/*.h instead of include/linux/tpm.h).
>> - many of the required functions are not exported.
>>
>> If the TPM maintainers are open to more of the API being "public", I
>> can look into preparing patches that export the necessary operations.
>>
>> 2) The second reason is that the initialization done by the driver is
>> work that should be done by platform, before the kernel ever sees the
>> TPM.
>
> This is too speculative to give any confirmitive promises. Do not fully
> understand the reasoning. For example: why should I care about
> out-of-tree modules?

You shouldn't care about out-of-tree modules, per se.  But the same
issues affect *in-tree* modules too.

Currently there is no way for an in-tree driver to accomplish all
three of the following

1) Disable the platform hierarchy (or set the platform auth password).
2) Use the TPM subsystem to accomplish step 1 (as opposed to
reimplementing startup, self-test, etc. which this driver currently
does).
3) Ensure that step 1 is done before the TPM is exposed to userspace
as /dev/tpmX (to prevent a race with userspace for control of the
platform hierarchy).

> I can look code changes but the text above contains
> too many words to nail anything down. I'm confused.

I see four possible resolutions:

1) Accept the code as is. No changes to the TPM subsystem. I do not
like this option.

2) Make more of the TPM driver API public (internally public) so that
the driver can reuse that code instead of reimplementing.  Not ideal,
as this could require major restructuring of the TPM code.

3) Allow the driver to register the TPM with TPM driver, but not yet
expose the TPM to userspace.  Let the driver do some additional work
(like set the platform hierarchy password) and then explicitly inform
the TPM driver that it is safe to expose the TPM to userspace.  This
would be my preferred approach.

4) The TPM driver (or daemon, perhaps. I don't under James's proposal
yet) sets the platform password.  As you say, this is an intrusive
change and only for a very specific use case right now. Perhaps not
ideal.

Do these make sense?

Best,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

On Wed, May 9, 2018 at 8:59 PM, Jarkko Sakkinen
 wrote:
> On Tue, May 08, 2018 at 08:36:25AM -0700, James Bottomley wrote:
>> Early boot means userspace. for a hot pluggable device, this would
>> probably be something in udev if you follow the no-daemon model and the
>> daemon could do it if you do follow the daemon model.
>>
>
> Could this be implemented as a first priority to daemon. If it turns out
> to be bad approach we can reconsider kernel. If we land it to kernel it
> is harder to take steps back.

Is the daemon an implementation of the TCG resource manager spec?

Best,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

On Wed, May 9, 2018 at 8:44 PM, Jarkko Sakkinen
<jarkko.sakki...@linux.intel.com> wrote:
> On Tue, May 08, 2018 at 10:29:41AM -0500, David R. Bild wrote:
>> On Tue, May 8, 2018 at 10:25 AM, James Bottomley
>> <james.bottom...@hansenpartnership.com> wrote:
>> >
>> > > On Fri, May 04, 2018 at 02:56:25PM -0500, David R. Bild wrote:
>> > [...]
>> > > > In particular, it sets the credentials for the platform hierarchy.
>> > > > The platform hierarchy is essentially the "root" account of the
>> > > > TPM, so it's critical that those credentials be set before the TPM
>> > > > is exposed to user-space.  (The platform credentials aren't
>> > > > persisted in the TPM and must be set by the platform on every
>> > > > boot.)  If the driver registers the TPM before doing
>> > > > initialization, there's a chance that something else could access
>> > > > the TPM before the platform credentials get set.
>> >
>
> Who is able to test these changes if we even consider pulling them?

I can send you and the other maintainers cards to test with. That's
dead simple.  (With a USB-A plug, not mini PCI-e, so you can plug it
into any computer.)

They won't have the Xaptum credentials pre-provisioned, and will just
function as normal TPMs.

> I do not have such a card so it will be hard to accept also given
> that it is more intrusive change than usual.

The current approach (the driver does all the initialization) requires
no changes to the TPM driver.  Only someone who buys our card will
ever run that code, so it doesn't impact anyone else.

Best,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

On Tue, May 8, 2018 at 10:36 AM, James Bottomley
<james.bottom...@hansenpartnership.com> wrote:
>
> On Tue, 2018-05-08 at 10:29 -0500, David R. Bild wrote:
> > On Tue, May 8, 2018 at 10:25 AM, James Bottomley
> > <james.bottom...@hansenpartnership.com> wrote:
> > >
> > > I don't see any reason to set an unreachable password for the
> > > platform
> > > hierarchy if the UEFI didn't.  If the desire is to disable the
> > > platform
> > > hierarchy, then it should be disabled, not have a random password
> > > set.
> >
> > "Set random password and throw away the key" was my way of disabling
> > the platform hierarchy.  Is there a better way of doing that?
>
> Well, yes, use TPM2_HierarchyControl to set phEnable to CLEAR.


I'm not sure that will work for us.  Let me give a little more detail
about this card.

The TPM holds access credentials for connecting to the Xaptum network.
This approach enables secure, zero-touch provisioning for IoT devices:
 Xaptum pre-provisions the TPMs *before* they are assembled onto a
device PCB. The device is shipped directly from factory to end
customer. The first time it turns on, the TPM is used to authenticate
the Xaptum network. Using a TPM protects the credentials from being
copied or duplicated by someone in the manufacturing chain.

These cards are designed for existing devices, like IoT gateways. You
can't add a TPM to an existing PCB, but you can plug in a mini PCI-e
card.

We provision the credentials (the DAA secret key, specifically) under
the platform hierarchy. The key can be used without platform
authorization, but not removed.  If we disable the platform hierarchy
entirely, I think the credentials will no longer be available for use.

> > > I'd also say this is probably the job of early boot based on
> > > policy.
> >
> > Agreed.  And since this card has no "early boot", the driver/kernel
> > need to do it.
>
> Early boot means userspace. for a hot pluggable device, this would
> probably be something in udev if you follow the no-daemon model and the
> daemon could do it if you do follow the daemon model.

Could you expand on the udev approach?  I might not understand enough
about udev (or the coming TPM resource manager changes) to follow the
suggestion.

This seems unsafe to me.  There's a race between a malicious userspace
program and the daemon to set the platform authorization.  If the
malicious program wins, it can reset the TPM, removing the
credentials, and the device won't be able to connect to the Xaptum
network. (This is a liveness concern, not safety.  A denial-of-service
attack, essentially.)

Best,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

On Tue, May 8, 2018 at 5:47 AM, Jarkko Sakkinen
<jarkko.sakki...@linux.intel.com> wrote:
>
> On Fri, May 04, 2018 at 08:00:22AM -0500, David R. Bild wrote:
> > Normally the system platform (i.e., BIOS/UEFI for x86) is responsible
> > for performing initialization of the TPM.  For these modules, the host
> > kernel is the platform, so we perform the initialization in the driver
> > before registering the TPM with the kernel TPM subsystem.
> >
> > The initialization consists of issuing the TPM startup command,
> > running the TPM self-test, and setting the TPM platform hierarchy
> > authorization to a random, unsaved value so that it can never be used
> > after the driver has loaded.
> >
> > Signed-off-by: David R. Bild <david.b...@xaptum.com>
>
> Have you checked what the TPM driver already does?


Yes.  It does the startup and self-test.

 However, this driver sets the platform hierarchy password *before*
giving the TPM to the TPM driver (thus, before the TPM driver can do
the startup and self-test).  Startup and self-test are prerequisites
for setting the platform hierarchy password, so this driver does those
itself too.

Best,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

On Tue, May 8, 2018 at 10:25 AM, James Bottomley
<james.bottom...@hansenpartnership.com> wrote:
>
> > On Fri, May 04, 2018 at 02:56:25PM -0500, David R. Bild wrote:
> [...]
> > > In particular, it sets the credentials for the platform hierarchy.
> > > The platform hierarchy is essentially the "root" account of the
> > > TPM, so it's critical that those credentials be set before the TPM
> > > is exposed to user-space.  (The platform credentials aren't
> > > persisted in the TPM and must be set by the platform on every
> > > boot.)  If the driver registers the TPM before doing
> > > initialization, there's a chance that something else could access
> > > the TPM before the platform credentials get set.
>
> I don't see any reason to set an unreachable password for the platform
> hierarchy if the UEFI didn't.  If the desire is to disable the platform
> hierarchy, then it should be disabled, not have a random password set.

"Set random password and throw away the key" was my way of disabling
the platform hierarchy.  Is there a better way of doing that?

> I'd also say this is probably the job of early boot based on policy.

Agreed.  And since this card has no "early boot", the driver/kernel
need to do it.

Best,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/2] usb: misc: xapea00x: add driver for Xaptum ENF Access Card

[David R. Bild]

On Mon, May 7, 2018 at 4:58 AM, Oliver Neukum <oneu...@suse.com> wrote:
>
> Am Freitag, den 04.05.2018, 08:00 -0500 schrieb  David R. Bild :
> >
> > +config USB_XAPEA00X
> > + tristate "Xaptum ENF Access card support (XAP-EA-00x)"
> > + depends on USB_SUPPORT && SPI && TCG_TPM
>
> You'd have to know how the device internally works. It would be better
> to select SPI.


That was my logic to Greg too. I'll change the SPI back to select.

> [..]
> > +/**
> > + * xapea00x_spi_probe - Register and configure the SPI master.
> > + * @dev: the device whose SPI master to register
> > + *
> > + * Return: If successful, 0. Otherwise a negative error number.
> > + */
> > +static int xapea00x_spi_probe(struct xapea00x_device *dev)
> > +{
> > + struct spi_master *spi_master;
> > + int retval;
> > +
> > + spi_master = spi_alloc_master(>interface->dev, sizeof(void *));
> > + if (!spi_master) {
> > + retval = -ENOMEM;
> > + goto err_out;
> > + }
> > +
> > + spi_master_set_devdata(spi_master, dev);
> > +
> > + spi_master->min_speed_hz = 93 * 1000 + 800; /* 93.9kHz */
> > + spi_master->max_speed_hz = 12 * 1000 * 1000; /* 12 MHz */
> > +
> > + spi_master->bus_num = -1; /* dynamically assigned */
> > + spi_master->num_chipselect = 1;
> > + spi_master->mode_bits = SPI_MODE_0;
> > +
> > + spi_master->flags = 0;
> > + spi_master->setup = xapea00x_spi_setup;
> > + spi_master->transfer_one_message = xapea00x_spi_transfer_one_message;
> > +
> > + retval = spi_register_master(spi_master);
> > +
> > + if (retval)
> > + goto free_spi;
> > +
> > + dev->spi_master = spi_master;
>
> Race condition.
>

What race condition do you see?  (I appreciate the review, but need
some more specific help here.)

>
> > +
> > + return 0;
> > +
> > +free_spi:
> > + spi_master_put(spi_master);
> > + dev->spi_master = NULL;
> > +
> > +err_out:
> > + return retval;
> > +}
> > +
>
> > +
> > +static struct spi_board_info tpm_board_info = {
> > + .modalias   = XAPEA00X_TPM_MODALIAS,
> > + .max_speed_hz   = 43 * 1000 * 1000, // Hz
>
> Are you hardcoding HZ ?


Yes. But it's the max speed of the SPI clock which is actually
specified in real HZ. It's not kernel "HZ".

Thanks for the other comments too; I'll incorporate into the next version.

Best,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

On Fri, May 4, 2018 at 2:56 PM, David R. Bild <david.b...@xaptum.com> wrote:
> 2) The second reason is that the initialization done by the driver is
> work that should be done by platform, before the kernel ever sees the
> TPM.
>
> In particular, it sets the credentials for the platform hierarchy.
> The platform hierarchy is essentially the "root" account of the TPM,
> so it's critical that those credentials be set before the TPM is
> exposed to user-space.  (The platform credentials aren't persisted in
> the TPM and must be set by the platform on every boot.)  If the driver
> registers the TPM before doing initialization, there's a chance that
> something else could access the TPM before the platform credentials
> get set.

Setting the platform hierarchy password to a random discarded value
(and the dictionary lockout reset) is really the only special work
done here. The other steps (startup, self test, etc.) are done by the
TPM subsystem if needed.

So easy option would be for the TPM subsystem to set the platform
hierarchy password to a random value during device registration, if
needed.  It could either

a) check if the platform hierarchy authorization is null and then
always set a random password

or

b) take a flag when the device is registered indicating whether to do this.

This wouldn't require a significant change to the TPM subsystem
internals and would let me drop nearly the entire second patch from
this series.  (I think the dictionary lockout reset can be done via
the already exported "tpm_send(...)" function.)

Any thoughts on this approach?

Best,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

On Fri, May 4, 2018 at 2:06 PM, Jason Gunthorpe <j...@ziepe.ca> wrote:
>
> On Fri, May 04, 2018 at 08:00:22AM -0500, David R. Bild wrote:
> > Normally the system platform (i.e., BIOS/UEFI for x86) is responsible
> > for performing initialization of the TPM.  For these modules, the host
> > kernel is the platform, so we perform the initialization in the driver
> > before registering the TPM with the kernel TPM subsystem.
>
> The tpm driver already does most of this stuff automatically, why
> duplicate it there and why is it coded in a way that doesn't use the
> existing TPM services to do it?

I didn't want to have to duplicate all that functionality and was
disappointed when that became the only option (due to the two reasons
outlined below) for supporting existing kernels with an out-of-tree
module.

Bringing the module in-tree opens the option of reworking some of the
TPM subsystem to support this use case.  I'm open to concrete
suggestions on how to do so.

1) The first reason is that I don't think the necessary pieces are
currently made available for reuse. I'd love to not repeat that code,
but

- some required structs and functions are declared in private headers
(drivers/char/tpm/*.h instead of include/linux/tpm.h).
- many of the required functions are not exported.

If the TPM maintainers are open to more of the API being "public", I
can look into preparing patches that export the necessary operations.

2) The second reason is that the initialization done by the driver is
work that should be done by platform, before the kernel ever sees the
TPM.

In particular, it sets the credentials for the platform hierarchy.
The platform hierarchy is essentially the "root" account of the TPM,
so it's critical that those credentials be set before the TPM is
exposed to user-space.  (The platform credentials aren't persisted in
the TPM and must be set by the platform on every boot.)  If the driver
registers the TPM before doing initialization, there's a chance that
something else could access the TPM before the platform credentials
get set.

The TPM system doesn't appear (to me; please correct me) to be
designed to support the following start-up sequence:

a) Driver registers the device with the TPM subsystem
b) Driver uses the TPM subsystem to perform platform initialization
(what the BIOS should have done...)
c) Driver tells the TPM subsystem to now perform the kernel
initialization of the TPM
d) TPM subsystem does its initialization of the TPM
e) TPM is exposed to userspace, added as hwrng, etc.

It would only support the sequence  [a, d, e, b] and we'd just have to
hope no one accesses the TPM between steps 'e' and 'b'.

Best,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

Normally the system platform (i.e., BIOS/UEFI for x86) is responsible
for performing initialization of the TPM.  For these modules, the host
kernel is the platform, so we perform the initialization in the driver
before registering the TPM with the kernel TPM subsystem.

The initialization consists of issuing the TPM startup command,
running the TPM self-test, and setting the TPM platform hierarchy
authorization to a random, unsaved value so that it can never be used
after the driver has loaded.

Signed-off-by: David R. Bild <david.b...@xaptum.com>
---
 drivers/usb/misc/xapea00x/Makefile|   3 +-
 drivers/usb/misc/xapea00x/xapea00x-core.c |  25 +
 drivers/usb/misc/xapea00x/xapea00x-tpm.c  | 952 ++
 3 files changed, 979 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-tpm.c

diff --git a/drivers/usb/misc/xapea00x/Makefile 
b/drivers/usb/misc/xapea00x/Makefile
index c4bcd7524c31..aa3f8803cdf5 100644
--- a/drivers/usb/misc/xapea00x/Makefile
+++ b/drivers/usb/misc/xapea00x/Makefile
@@ -4,4 +4,5 @@
 #
 obj-$(CONFIG_USB_XAPEA00X) += xapea00x.o
 
-xapea00x-y += xapea00x-core.o xapea00x-bridge.o
+xapea00x-y += xapea00x-core.o xapea00x-bridge.o xapea00x-tpm.o
+
diff --git a/drivers/usb/misc/xapea00x/xapea00x-core.c 
b/drivers/usb/misc/xapea00x/xapea00x-core.c
index 885bcda9c01d..53e82f8b38f3 100644
--- a/drivers/usb/misc/xapea00x/xapea00x-core.c
+++ b/drivers/usb/misc/xapea00x/xapea00x-core.c
@@ -280,6 +280,31 @@ static void xapea00x_tpm_probe(struct work_struct *work)
struct spi_device *tpm;
int retval;
 
+   mutex_lock(>usb_mutex);
+   if (!dev->interface) {
+   retval = -ENODEV;
+   goto out;
+   }
+   /*
+* This driver is the "platform" in TPM terminology. Before
+* passing control of the TPM to the Linux TPM subsystem, do
+* the TPM initialization normally done by the platform code
+* (e.g., BIOS).
+*/
+   retval = xapea00x_tpm_platform_initialize(dev);
+   if (retval) {
+   dev_err(>interface->dev,
+   "unable to do TPM platform initialization: %d\n",
+   retval);
+   goto err;
+   }
+
+   /*
+* Now register the TPM with the Linux TPM subsystem.  This
+* may call through to xapea00x_spi_transfer_one_message(), so
+* don't hold usb_mutex here.
+*/
+   mutex_unlock(>usb_mutex);
tpm = spi_new_device(spi_master, _board_info);
mutex_lock(>usb_mutex);
if (!dev->interface) {
diff --git a/drivers/usb/misc/xapea00x/xapea00x-tpm.c 
b/drivers/usb/misc/xapea00x/xapea00x-tpm.c
new file mode 100644
index ..27159043ce3c
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/xapea00x-tpm.c
@@ -0,0 +1,952 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Driver for the XAP-EA-00x series of the Xaptum Edge Access Card, a
+ *  TPM 2.0-based hardware module for authenticating IoT devices and
+ *  gateways.
+ *
+ *  Copyright (c) 2017-2018 Xaptum, Inc.
+ */
+
+#include "xapea00x.h"
+
+#define TPM_RETRY  50
+#define TPM_TIMEOUT5// msecs
+#define TPM_TIMEOUT_RANGE_US   300  // usecs
+
+#define TIS_SHORT_TIMEOUT  750  // msecs
+#define TIS_LONG_TIMEOUT   2000 // msecs
+
+#define TIS_MAX_BUF1024 // byte
+#define TIS_HEADER_LEN 10   // byte
+
+#define TPM2_TIMEOUT_A 750  // msecs
+#define TPM2_TIMEOUT_B 2000 // msecs
+#define TPM2_TIMEOUT_C 200  // msecs
+#define TPM2_TIMEOUT_D 30   // msecs
+
+#define TPM_ACCESS_0   0x
+#define TPM_STS_0  0x0018
+#define TPM_DATA_FIFO_00x0024
+
+#define TPM2_ST_NO_SESSIONS0x8001
+#define TPM2_ST_SESSIONS   0x8002
+
+#define TPM2_CC_STARTUP0x0144
+#define TPM2_CC_SHUTDOWN   0x0145
+#define TPM2_CC_SELF_TEST  0x0143
+#define TPM2_CC_GET_RANDOM 0x017B
+#define TPM2_CC_HIERARCHY_CHANGE_AUTH  0x0129
+#define TPM2_CC_DICT_ATTACK_LOCK_RST   0x0139
+
+#define TPM_RC_SUCCESS 0x000
+#define TPM_RC_INITIALIZE  0x100
+
+enum tis_access {
+   TPM_ACCESS_VALID= 0x80,
+   TPM_ACCESS_ACTIVE_LOCALITY  = 0x20,
+   TPM_ACCESS_REQUEST_PENDING  = 0x04,
+   TPM_ACCESS_REQUEST_USE  = 0x02
+};
+
+enum tis_status {
+   TPM_STS_VALID   = 0x80,
+   TPM_STS_COMMAND_READY   = 0x40,
+   TPM_STS_GO  = 0x20,
+   TPM_STS_DATA_AVAIL  = 0x10,
+   TPM_STS_DATA_EXPECT = 0x08,
+   TPM_STS_SELF_TEST_DONE  = 0x04,
+   TPM_STS_RESPONSE_RETRY  = 0x02
+};
+
+struct tpm_tis_command {
+   __be16 tag;
+   __be32 size;
+   __be32 c

[PATCH v3 0/2] Add driver for Xaptum ENF Access card (XAP-EA-00x)

[David R. Bild]

This series add a driver for the Xaptum ENF Access card line
(XAP-EA-00x), a series of mini PCI-e cards containing a TPM 2.0 chip
used to authenticate IoT devices and gateways.

The hardware is essentially a USB-SPI bridge and an SPI TPM 2.0
chip. The first patch registers the bridge as an SPI controller and
the TPM as an SPI device. The second patch performs the TPM platform
initialization that would normally be done by the BIOS.

The TPM portions need review from the TPM maintainers, before Greg can
accept it in the USB tree.

Changes since v2:
 * Depend on (not select) SPI and TPM support
 * Remove noisy logging
 * Do not explicitly specify MODULE_ALIAS
 * Use KBUILD_MODNAME macro for module name
 * Clean up formatting & indentation

David R. Bild (2):
  usb: misc: xapea00x: add driver for Xaptum ENF Access Card
  usb: misc: xapea00x: perform platform initialization of TPM

 MAINTAINERS |   6 +
 drivers/usb/misc/Kconfig|   2 +
 drivers/usb/misc/Makefile   |   1 +
 drivers/usb/misc/xapea00x/Kconfig   |  14 +
 drivers/usb/misc/xapea00x/Makefile  |   8 +
 drivers/usb/misc/xapea00x/xapea00x-bridge.c | 380 +++
 drivers/usb/misc/xapea00x/xapea00x-core.c   | 433 +
 drivers/usb/misc/xapea00x/xapea00x-spi.c| 196 ++
 drivers/usb/misc/xapea00x/xapea00x-tpm.c| 952 
 drivers/usb/misc/xapea00x/xapea00x.h|  75 +++
 10 files changed, 2067 insertions(+)
 create mode 100644 drivers/usb/misc/xapea00x/Kconfig
 create mode 100644 drivers/usb/misc/xapea00x/Makefile
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-bridge.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-core.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-spi.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-tpm.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x.h

-- 
2.16.3

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/2] usb: misc: xapea00x: add driver for Xaptum ENF Access Card

[David R. Bild]

This commit adds a driver for the Xaptum ENF Access Card, a TPM2.0
hardware module for authenticating IoT devices and gateways.

The card consists of a SPI TPM 2.0 chip and a USB-SPI bridge. This
driver configures the bridge, registers the bridge as an SPI
controller, and adds the TPM 2.0 as an SPI device.  The in-kernel TPM
2.0 driver is then automatically loaded to configure the TPM and
expose it to userspace.

Signed-off-by: David R. Bild <david.b...@xaptum.com>
---
 MAINTAINERS |   6 +
 drivers/usb/misc/Kconfig|   2 +
 drivers/usb/misc/Makefile   |   1 +
 drivers/usb/misc/xapea00x/Kconfig   |  14 +
 drivers/usb/misc/xapea00x/Makefile  |   7 +
 drivers/usb/misc/xapea00x/xapea00x-bridge.c | 380 ++
 drivers/usb/misc/xapea00x/xapea00x-core.c   | 408 
 drivers/usb/misc/xapea00x/xapea00x-spi.c| 196 +
 drivers/usb/misc/xapea00x/xapea00x.h|  75 +
 9 files changed, 1089 insertions(+)
 create mode 100644 drivers/usb/misc/xapea00x/Kconfig
 create mode 100644 drivers/usb/misc/xapea00x/Makefile
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-bridge.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-core.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-spi.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x.h

diff --git a/MAINTAINERS b/MAINTAINERS
index b1ccabd0dbc3..77d35444ef1c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14796,6 +14796,12 @@ L: linux-wirel...@vger.kernel.org
 S: Maintained
 F: drivers/net/wireless/rndis_wlan.c
 
+USB XAPEA00X DRIVER
+M: David R. Bild <david.b...@xaptum.com>
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/usb/misc/xapea00x/
+
 USB XHCI DRIVER
 M: Mathias Nyman <mathias.ny...@intel.com>
 L: linux-usb@vger.kernel.org
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 68d2f2cd17dd..747d7f03fb84 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -275,3 +275,5 @@ config USB_CHAOSKEY
 
  To compile this driver as a module, choose M here: the
  module will be called chaoskey.
+
+source "drivers/usb/misc/xapea00x/Kconfig"
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 109f54f5b9aa..f3583501547c 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -30,4 +30,5 @@ obj-$(CONFIG_USB_HSIC_USB4604)+= usb4604.o
 obj-$(CONFIG_USB_CHAOSKEY) += chaoskey.o
 
 obj-$(CONFIG_USB_SISUSBVGA)+= sisusbvga/
+obj-$(CONFIG_USB_XAPEA00X) += xapea00x/
 obj-$(CONFIG_USB_LINK_LAYER_TEST)  += lvstest.o
diff --git a/drivers/usb/misc/xapea00x/Kconfig 
b/drivers/usb/misc/xapea00x/Kconfig
new file mode 100644
index ..bea57c8cca53
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/Kconfig
@@ -0,0 +1,14 @@
+config USB_XAPEA00X
+   tristate "Xaptum ENF Access card support (XAP-EA-00x)"
+   depends on USB_SUPPORT && SPI && TCG_TPM
+   select TCG_TIS_SPI
+   help
+ Say Y here if you want to support the Xaptum ENF Access
+ modules (XAP-EA-00x) in the USB or Mini PCI-e form
+ factors. The XAP-EA-00x module exposes a TPM 2.0 as
+ /dev/tpmX to use for authenticating with the Xaptum ENF.
+
+ To compile this driver as a module, choose M here. The
+ module will be called xapea00x.
+
+ If unsure, say M.
diff --git a/drivers/usb/misc/xapea00x/Makefile 
b/drivers/usb/misc/xapea00x/Makefile
new file mode 100644
index ..c4bcd7524c31
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for the xapea00x driver.
+#
+obj-$(CONFIG_USB_XAPEA00X) += xapea00x.o
+
+xapea00x-y += xapea00x-core.o xapea00x-bridge.o
diff --git a/drivers/usb/misc/xapea00x/xapea00x-bridge.c 
b/drivers/usb/misc/xapea00x/xapea00x-bridge.c
new file mode 100644
index ..7071431dea96
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/xapea00x-bridge.c
@@ -0,0 +1,380 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Driver for the XAP-EA-00x series of the Xaptum Edge Access Card, a
+ *  TPM 2.0-based hardware module for authenticating IoT devices and
+ *  gateways.
+ *
+ *  Copyright (c) 2017-2018 Xaptum, Inc.
+ */
+
+#include "xapea00x.h"
+
+#define XAPEA00X_BR_CMD_READ   0x00
+#define XAPEA00X_BR_CMD_WRITE  0x01
+#define XAPEA00X_BR_CMD_WRITEREAD  0x02
+
+#define XAPEA00X_BR_BREQTYP_SET0x40
+
+#define XAPEA00X_BR_BREQ_SET_GPIO_VALUES   0x21
+#define XAPEA00X_BR_BREQ_SET_GPIO_CS   0x25
+#define XAPEA00X_BR_BREQ_SET_SPI_WORD  0x31
+
+#define XAPEA00X_BR_USB_TIMEOUT1000 // msecs
+
+#define XAPEA00X_BR_CS_DISABLED0x00
+
+/**

Re: [PATCH v2 1/2] usb: misc: xapea00x: add driver for Xaptum ENF Access Card

[David R. Bild]

On Mon, Apr 30, 2018 at 11:05 AM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
>
> On Mon, Apr 30, 2018 at 07:54:17AM -0500, David R. Bild wrote:
> > This commit adds a driver for the Xaptum ENF Access Card, a TPM2.0
> > hardware module for authenticating IoT devices and gateways.
> >
> Overall it looks good to me, but you should
> also get the TPM maintainers/developers to review it as I will require
> their review before I can take it in the USB tree.

Thanks for the review.

> > --- /dev/null
> > +++ b/drivers/usb/misc/xapea00x/Kconfig
> > @@ -0,0 +1,16 @@
> > +config  USB_XAPEA00X
> > +tristate "Xaptum ENF Access card support (XAP-EA-00x)"
> > +depends on USB_SUPPORT
> > +select SPI
> > +select TCG_TPM
> > +select TCG_TIS_SPI
>
> Do you really want to 'select' these?  Why not just depend on them?

Here's my reasoning, but I'm happy to change to "depends" if that
better follows common practice.

The device is a USB device and thus will only work on a machine with a
USB host. That's a property of the machine, so we just "depend" on it.

The SPI and TPM support requirements are internal to the device driver
(the device is SPI master, SPI device, and TPM).  This driver needs
those systems enabled, but doesn't require any explicit SPI or TPM
support on the machine (e.g., a physical SPI master).  Someone might
want to build a kernel with this driver, but would have no reason to
explicitly enable the SPI or TPM subsystems (after all, the machine
may not have any SPI or TPM hardware).  So we "select" those here.

(I can also see using logic to argue for depending on USB_SUPPORT and
TCG_TPM, but selecting SPI and TCG_TIS_SPI...)

In the absence of any other guidance, that was my logic.  I'm happy to
change to "depends".

> > +struct xapea00x_device {
> > + struct kref kref;
> > +
> > + struct usb_device *udev;
> > + /*
> > +  * The interface pointer will be set NULL when the device
> > +  * disconnects.  Accessing it safe only while holding the
> > +  * usb_mutex.
> > +  */
> > + struct usb_interface *interface;
> > + /*
> > +  * Th usb_mutex must be held while synchronous USB requests are
> > +  * in progress. It is acquired during disconnect to be sure
> > +  * that there is not an outstanding request.
> > +  */
> > + struct mutex usb_mutex;
> > +
> > + struct usb_endpoint_descriptor *bulk_in;
> > + struct usb_endpoint_descriptor *bulk_out;
> > +
> > + u16 pid;
> > + u16 vid;
>
> Why do you care about these vid/pid values?  You set them and never use
> them.  If you really needed them, you can get them from the pointer to
> the interface above.

They are used in the TPM initialization code (`xapea00x-tpm.c`).
There are a couple of models of xap-ea-00x with differing
initialization requirements.

Is there a shorter way to get the pid from the usb_device than
__le16_to_cpu(udev->descriptor.idProduct);
?

I found it cleaner to pull that out into a variable once, rather than
fill the TPM-specific code with that very USB-specific code.

Thanks,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

Normally the system platform (i.e., BIOS/UEFI for x86) is responsible
for performing initialization of the TPM.  For these modules, the host
kernel is the platform, so we perform the initialization in the driver
before registering the TPM with the kernel TPM subsystem.

The initialization consists of issuing the TPM startup command,
running the TPM self-test, and setting the TPM platform hierarchy
authorization to a random, unsaved value so that it can never be used
after the driver has loaded.

Signed-off-by: David R. Bild <david.b...@xaptum.com>
---
 drivers/usb/misc/xapea00x/Makefile|   3 +-
 drivers/usb/misc/xapea00x/xapea00x-core.c |  25 +
 drivers/usb/misc/xapea00x/xapea00x-tpm.c  | 954 ++
 3 files changed, 981 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-tpm.c

diff --git a/drivers/usb/misc/xapea00x/Makefile 
b/drivers/usb/misc/xapea00x/Makefile
index c4bcd7524c31..aa3f8803cdf5 100644
--- a/drivers/usb/misc/xapea00x/Makefile
+++ b/drivers/usb/misc/xapea00x/Makefile
@@ -4,4 +4,5 @@
 #
 obj-$(CONFIG_USB_XAPEA00X) += xapea00x.o
 
-xapea00x-y += xapea00x-core.o xapea00x-bridge.o
+xapea00x-y += xapea00x-core.o xapea00x-bridge.o xapea00x-tpm.o
+
diff --git a/drivers/usb/misc/xapea00x/xapea00x-core.c 
b/drivers/usb/misc/xapea00x/xapea00x-core.c
index 68caf3bf9be6..a1be7796295d 100644
--- a/drivers/usb/misc/xapea00x/xapea00x-core.c
+++ b/drivers/usb/misc/xapea00x/xapea00x-core.c
@@ -285,6 +285,31 @@ static void xapea00x_tpm_probe(struct work_struct *work)
struct spi_device *tpm;
int retval;
 
+   mutex_lock(>usb_mutex);
+   if (!dev->interface) {
+   retval = -ENODEV;
+   goto out;
+   }
+   /*
+* This driver is the "platform" in TPM terminology. Before
+* passing control of the TPM to the Linux TPM subsystem, do
+* the TPM initialization normally done by the platform code
+* (e.g., BIOS).
+*/
+   retval = xapea00x_tpm_platform_initialize(dev);
+   if (retval) {
+   dev_err(>interface->dev,
+   "unable to do TPM platform initialization: %d\n",
+   retval);
+   goto err;
+   }
+
+   /*
+* Now register the TPM with the Linux TPM subsystem.  This
+* may call through to xapea00x_spi_transfer_one_message(), so
+* don't hold usb_mutex here.
+*/
+   mutex_unlock(>usb_mutex);
tpm = spi_new_device(spi_master, _board_info);
mutex_lock(>usb_mutex);
if (!dev->interface) {
diff --git a/drivers/usb/misc/xapea00x/xapea00x-tpm.c 
b/drivers/usb/misc/xapea00x/xapea00x-tpm.c
new file mode 100644
index ..d0e5c5b6d75d
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/xapea00x-tpm.c
@@ -0,0 +1,954 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Driver for the XAP-EA-00x series of the Xaptum Edge Access Card, a
+ *  TPM 2.0-based hardware module for authenticating IoT devices and
+ *  gateways.
+ *
+ *  Copyright (c) 2017 Xaptum, Inc.
+ */
+
+#include "xapea00x.h"
+
+#define TPM_RETRY 50
+#define TPM_TIMEOUT   5// msecs
+#define TPM_TIMEOUT_RANGE_US  300  // usecs
+
+#define TIS_SHORT_TIMEOUT 750  // msecs
+#define TIS_LONG_TIMEOUT  2000 // msecs
+
+#define TIS_MAX_BUF   1024 // byte
+#define TIS_HEADER_LEN10   // byte
+
+#define TPM2_TIMEOUT_A750  // msecs
+#define TPM2_TIMEOUT_B2000 // msecs
+#define TPM2_TIMEOUT_C200  // msecs
+#define TPM2_TIMEOUT_D30   // msecs
+
+#define TPM_ACCESS_0  0x
+#define TPM_STS_0 0x0018
+#define TPM_DATA_FIFO_0   0x0024
+
+#define TPM2_ST_NO_SESSIONS   0x8001
+#define TPM2_ST_SESSIONS  0x8002
+
+#define TPM2_CC_STARTUP   0x0144
+#define TPM2_CC_SHUTDOWN  0x0145
+#define TPM2_CC_SELF_TEST 0x0143
+#define TPM2_CC_GET_RANDOM0x017B
+#define TPM2_CC_HIERARCHY_CHANGE_AUTH  0x0129
+#define TPM2_CC_DICT_ATTACK_LOCK_RST   0x0139
+
+#define TPM_RC_SUCCESS0x000
+#define TPM_RC_INITIALIZE 0x100
+
+enum tis_access {
+   TPM_ACCESS_VALID = 0x80,
+   TPM_ACCESS_ACTIVE_LOCALITY = 0x20,
+   TPM_ACCESS_REQUEST_PENDING = 0x04,
+   TPM_ACCESS_REQUEST_USE = 0x02
+};
+
+enum tis_status {
+   TPM_STS_VALID  = 0x80,
+   TPM_STS_COMMAND_READY  = 0x40,
+   TPM_STS_GO = 0x20,
+   TPM_STS_DATA_AVAIL = 0x10,
+   TPM_STS_DATA_EXPECT= 0x08,
+   TPM_STS_SELF_TEST_DONE = 0x04,
+   TPM_STS_RESPONSE_RETRY = 0x02
+};
+
+struct tpm_tis_command {
+   __be16 tag;
+   __be32 size;
+   __be32 c

[PATCH v2 1/2] usb: misc: xapea00x: add driver for Xaptum ENF Access Card

[David R. Bild]

This commit adds a driver for the Xaptum ENF Access Card, a TPM2.0
hardware module for authenticating IoT devices and gateways.

The card consists of a SPI TPM 2.0 chip and a USB-SPI bridge. This
driver configures the bridge, registers the bridge as an SPI
controller, and adds the TPM 2.0 as an SPI device.  The in-kernel TPM
2.0 driver is then automatically loaded to configure the TPM and
expose it to userspace.

Signed-off-by: David R. Bild <david.b...@xaptum.com>
---
 MAINTAINERS |   6 +
 drivers/usb/misc/Kconfig|   2 +
 drivers/usb/misc/Makefile   |   1 +
 drivers/usb/misc/xapea00x/Kconfig   |  16 ++
 drivers/usb/misc/xapea00x/Makefile  |   7 +
 drivers/usb/misc/xapea00x/xapea00x-bridge.c | 400 ++
 drivers/usb/misc/xapea00x/xapea00x-core.c   | 426 
 drivers/usb/misc/xapea00x/xapea00x-spi.c| 209 ++
 drivers/usb/misc/xapea00x/xapea00x.h|  75 +
 9 files changed, 1142 insertions(+)
 create mode 100644 drivers/usb/misc/xapea00x/Kconfig
 create mode 100644 drivers/usb/misc/xapea00x/Makefile
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-bridge.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-core.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-spi.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 79bb02ff812f..c0e34a3ef5aa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14795,6 +14795,12 @@ L: linux-wirel...@vger.kernel.org
 S: Maintained
 F: drivers/net/wireless/rndis_wlan.c
 
+USB XAPEA00X DRIVER
+M: David R. Bild <david.b...@xaptum.com>
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/usb/misc/xapea00x/
+
 USB XHCI DRIVER
 M: Mathias Nyman <mathias.ny...@intel.com>
 L: linux-usb@vger.kernel.org
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 68d2f2cd17dd..747d7f03fb84 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -275,3 +275,5 @@ config USB_CHAOSKEY
 
  To compile this driver as a module, choose M here: the
  module will be called chaoskey.
+
+source "drivers/usb/misc/xapea00x/Kconfig"
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 109f54f5b9aa..f3583501547c 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -30,4 +30,5 @@ obj-$(CONFIG_USB_HSIC_USB4604)+= usb4604.o
 obj-$(CONFIG_USB_CHAOSKEY) += chaoskey.o
 
 obj-$(CONFIG_USB_SISUSBVGA)+= sisusbvga/
+obj-$(CONFIG_USB_XAPEA00X) += xapea00x/
 obj-$(CONFIG_USB_LINK_LAYER_TEST)  += lvstest.o
diff --git a/drivers/usb/misc/xapea00x/Kconfig 
b/drivers/usb/misc/xapea00x/Kconfig
new file mode 100644
index ..56c11f6ee7b3
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/Kconfig
@@ -0,0 +1,16 @@
+config  USB_XAPEA00X
+tristate "Xaptum ENF Access card support (XAP-EA-00x)"
+depends on USB_SUPPORT
+select SPI
+select TCG_TPM
+select TCG_TIS_SPI
+help
+  Say Y here if you want to support the Xaptum ENF Access
+  modules (XAP-EA-00x) in the USB or Mini PCI-e form
+  factors. The XAP-EA-00x module exposes a TPM 2.0 as
+  /dev/tpmX to use for authenticating with the Xaptum ENF.
+
+  To compile this driver as a module, choose M here. The
+  module will be called xapea00x.
+
+  If unsure, say M.
diff --git a/drivers/usb/misc/xapea00x/Makefile 
b/drivers/usb/misc/xapea00x/Makefile
new file mode 100644
index ..c4bcd7524c31
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for the xapea00x driver.
+#
+obj-$(CONFIG_USB_XAPEA00X) += xapea00x.o
+
+xapea00x-y += xapea00x-core.o xapea00x-bridge.o
diff --git a/drivers/usb/misc/xapea00x/xapea00x-bridge.c 
b/drivers/usb/misc/xapea00x/xapea00x-bridge.c
new file mode 100644
index ..6d78e83d96f6
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/xapea00x-bridge.c
@@ -0,0 +1,400 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Driver for the XAP-EA-00x series of the Xaptum Edge Access Card, a
+ *  TPM 2.0-based hardware module for authenticating IoT devices and
+ *  gateways.
+ *
+ *  Copyright (c) 2017 Xaptum, Inc.
+ */
+
+#include "xapea00x.h"
+
+#define XAPEA00X_BR_CMD_READ 0x00
+#define XAPEA00X_BR_CMD_WRITE0x01
+#define XAPEA00X_BR_CMD_WRITEREAD0x02
+
+#define XAPEA00X_BR_BREQTYP_SET  0x40
+
+#define XAPEA00X_BR_BREQ_SET_GPIO_VALUES  0x21
+#define XAPEA00X_BR_BREQ_SET_GPIO_CS 0x25
+#define XAPEA00X_BR_BREQ_SET_SPI_WORD0x31
+
+#define XAPEA00X_BR_USB_TIMEOUT  1000 // msecs
+
+#defi

[PATCH v2 0/2] Add driver for Xaptum ENF Access card (XAP-EA-00x)

[David R. Bild]

This commit adds a driver for the Xaptum ENF Access Card, a TPM2.0
hardware module for authenticating IoT devices and gateways.

The card consists of a SPI TPM 2.0 chip and a USB-SPI bridge. This
driver configures the bridge, registers the bridge as an SPI
controller, and adds the TPM 2.0 as an SPI device.  The in-kernel TPM
2.0 driver is then automatically loaded to configure the TPM and
expose it to userspace.

Changes since v1:
 * Remove empty spi cleanup function
 * Fix __beXX/__eXX mismatches
 * Correct typos in comments
 * Add break to last case of switch
 * Check result of kzalloc

David R. Bild (2):
  usb: misc: xapea00x: add driver for Xaptum ENF Access Card
  usb: misc: xapea00x: perform platform initialization of TPM

 MAINTAINERS |   6 +
 drivers/usb/misc/Kconfig|   2 +
 drivers/usb/misc/Makefile   |   1 +
 drivers/usb/misc/xapea00x/Kconfig   |  16 +
 drivers/usb/misc/xapea00x/Makefile  |   8 +
 drivers/usb/misc/xapea00x/xapea00x-bridge.c | 400 
 drivers/usb/misc/xapea00x/xapea00x-core.c   | 451 +
 drivers/usb/misc/xapea00x/xapea00x-spi.c| 209 ++
 drivers/usb/misc/xapea00x/xapea00x-tpm.c| 954 
 drivers/usb/misc/xapea00x/xapea00x.h|  75 +++
 10 files changed, 2122 insertions(+)
 create mode 100644 drivers/usb/misc/xapea00x/Kconfig
 create mode 100644 drivers/usb/misc/xapea00x/Makefile
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-bridge.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-core.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-spi.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-tpm.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x.h

-- 
2.16.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: misc: xapea00x: add driver for Xaptum ENF Access Card

[David R. Bild]

On Thu, Jan 25, 2018 at 10:34 AM, David R. Bild <david.b...@xaptum.com> wrote:
> On Thu, Jan 11, 2018 at 4:27 AM, Oliver Neukum <oneu...@suse.com> wrote:
>>
>> Am Mittwoch, den 10.01.2018, 10:58 -0600 schrieb  David R. Bild :
>
>> > +static void xapea00x_tpm_probe(struct work_struct *work)
>> > +{
>> > + struct xapea00x_async_probe *probe = work_to_probe(work);
>> > + struct xapea00x_device *dev = probe->dev;
>> > + struct spi_master *spi_master = dev->spi_master;
>> > + struct spi_device *tpm;
>> > + int retval;
>> > +
>> > + tpm = spi_new_device(spi_master, _board_info);
>> > + mutex_lock(>usb_mutex);
>> > + if (!dev->interface) {
>> > + retval = -ENODEV;
>> > + goto out;
>> > + }
>> > + if (!tpm) {
>>
>> Why test this under a mutex?
>>
>
> dev->interface being NULL/non-NULL is used as a flag to determine if
> the USB device has been unregistered.  So, the mutex needs to be held
> when dereferencing dev->interface subsequently.
>
> Performing the test before acquiring the lock would be a race condition.
>

I'm realizing I misunderstood this comment --- you're referring to
testing "!tpm", not testing "!dev->interface".

It's because the in the failure case (!tpm), I want the error message
to include the "dev->interface->dev" identifier.  But that
dereferencing is only safe if "dev->interface" isn't NULL.

>> > + retval = -ENODEV;
>> > + dev_err(>interface->dev,
>> > + "unable to add spi device for TPM\n");
>> > + goto err;
>> > + }
>> > +


Thanks much,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: misc: xapea00x: add driver for Xaptum ENF Access Card

[David R. Bild]

On Thu, Jan 11, 2018 at 4:27 AM, Oliver Neukum <oneu...@suse.com> wrote:
>
> Am Mittwoch, den 10.01.2018, 10:58 -0600 schrieb  David R. Bild :
> > This commit adds a driver for the Xaptum ENF Access Card, a TPM2.0
> > hardware module for authenticating IoT devices and gateways.
> >

Thanks for the review. Fixed a couple of definite bugs.

Responses (or requests for clarification) for some of your comments
follow.  The others are fixed in a v2, which I'll sent once you answer
my clarifying questions.

> > +static int xapea00x_br_bulk_write(struct xapea00x_device *dev,
> > +   struct xapea00x_br_bulk_command *header,
> > +   const void *data, int len)
> > +{
> > + u8 *buf;
> > + unsigned int pipe;
> > + int buf_len, actual_len, retval;
> > +
> > + buf_len = sizeof(struct xapea00x_br_bulk_command) + len;
> > + buf = kzalloc(buf_len, GFP_KERNEL);
>
> Why zeroed? You copy all over it.

It's easiest to audit the code for incorrect usages of kalloc if we
just always use kzalloc.

This device isn't used very frequently --- once shortly after boot if
used correctly and once each time the internet connection is
re-established if used poorly.  Each use sends just a couple KB
between device and host.  So I'd rather optimize for ease of
functional correctness and safety than saving the few cycles needed to
zero something that is immediately overwritten.

Same logic for using kzfree everywhere, even on structures or buffers
that don't contain user or other potentially sensitive data.

> > + memcpy(buf, header, sizeof(struct xapea00x_br_bulk_command));
> > + memcpy(buf + sizeof(struct xapea00x_br_bulk_command), data, len);
> > +
> > + pipe = usb_sndbulkpipe(dev->udev, dev->bulk_out->bEndpointAddress);
> > + retval = usb_bulk_msg(dev->udev, pipe, buf, buf_len, _len,
> > +   XAPEA00X_BR_USB_TIMEOUT);
> > + if (retval) {
> > + dev_warn(>interface->dev,
> > +  "%s: usb_bulk_msg() failed with %d\n",
> > +  __func__, retval);
> > + goto free_buf;
>
> Does this make any sense?

It does to me.  What specifically do you think is odd?

> > + }
> > +
> > + retval = 0;
> > +
> > +free_buf:
> > + kzfree(buf);
> > +
> > +out:
> > + return retval;
> > +}

> > +static int xapea00x_br_ctrl_write(struct xapea00x_device *dev, u8 bRequest,
> > +   u16 wValue, u16 wIndex, u8 *data, u16 len)
>
> Combine with xapea00x_br_bulk_write()?

No.  xapea00x_br_bulk_write and xapea00x_br_ctrl_write conceptually do
very different things and take very different parameters.

> > +static int xapea00x_spi_setup(struct spi_device *spi)
> > +{
> > + struct xapea00x_device *dev;
> > + int retval;
> > +
> > + dev = spi_master_get_devdata(spi->master);
> > +
> > + mutex_lock(>usb_mutex);
> > + if (!dev->interface) {
> > + retval = -ENODEV;
> > + goto out;
> > + }
> > +
> > + /* Verify that this is the TPM device */
> > + if (spi->chip_select != 0) {
> > + retval = -EINVAL;
> > + goto err;
> > + }
> > +
> > + /*
> > +  * Disable auto chip select for the TPM channel.
> > +  * Must be done after setting the SPI parameters.
> > +  */
> > + retval = xapea00x_br_disable_cs(dev, 0);
> > + if (retval)
> > + goto err;
> > +
> > + /* De-assert chip select for the TPM channel. */
> > + retval = xapea00x_br_deassert_cs(dev, 0);
> > + if (retval)
> > + goto err;
> > +
> > + dev_dbg(>interface->dev, "configured spi channel for tpm\n");
> > + retval = 0;
> > + goto out;
>
> The control flow is innovative.

Thanks ;)

I've removed the "retval = 0;" as that is unnecessary.  Otherwise, do
you have a better control flow that doesn't involve repeating either
the following "dev_err" or "mutex_unlock".  I've found this style to
be the safest in the face of future changes.

> > +
> > +err:
> > + dev_err(>interface->dev,
> > + "configuring SPI channel failed with %d\n", retval);
> > +
> > +out:
> > + mutex_unlock(>usb_mutex);
> > + return retval;
> > +}
> > +

> > + /* Deassert chip select, if requested */
> > + if (!cs_hold)
> > + 

Re: [PATCH 1/2] usb: misc: xapea00x: add driver for Xaptum ENF Access Card

[David R. Bild]

On Mon, Jan 22, 2018 at 8:28 AM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
>
> On Wed, Jan 10, 2018 at 10:58:29AM -0600, David R. Bild wrote:
> > +/**
> > + * xapea00x_spi_cleanup
> > + *
> > + * Context: !in_interrupt()
> > + */
>
> No need to have kerneldoc formatting for static functions, nor the whole
> Context thing, but it's your code to maintain over time, not mine :)

It's somewhat helpful for new folks on our team who need to follow the
code, although rather verbose afterwards. If you think it's too
verbose by kernel standards, I'm happy to de-kerneldoc the static
functions.

>
>
> > +static void xapea00x_spi_cleanup(struct spi_device *spi)
> > +{
> > + dev_dbg(>dev, "%s\n", __func__);
> > +}
>
> Why?  Why is this function here at all?

I'll remove this method in v2 when addressing Oliver's comments.  The
SPI subsystem does allow a null pointer for the cleanup callback. I
didn't think it did based on some examples I'd been looking at ---
hence the no-op function.

> Shouldn't you be actually cleaning up some memory or reference count
> here?

In this case, there's nothing to free or decrement.  All cleanup is
done when the USB device is unregistered.

Thanks,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

Normally the system platform (i.e., BIOS/UEFI for x86) is responsible
for performing intialization of the TPM.  For these modules, the host
kernel is the platform, so we perform the initialization in the driver
before registering the TPM with the kernel TPM subsystem.

The initialization consists of issuing the TPM startup command,
running the TPM self-test, and setting the TPM platform hierarchy
authorization to a random, unsaved value so that it can never be used
after the driver has loaded.

Signed-off-by: David R. Bild <david.b...@xaptum.com>
---
 drivers/usb/misc/xapea00x/Makefile|   3 +-
 drivers/usb/misc/xapea00x/xapea00x-core.c |  25 +
 drivers/usb/misc/xapea00x/xapea00x-tpm.c  | 954 ++
 3 files changed, 981 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-tpm.c

diff --git a/drivers/usb/misc/xapea00x/Makefile 
b/drivers/usb/misc/xapea00x/Makefile
index c4bcd7524c31..aa3f8803cdf5 100644
--- a/drivers/usb/misc/xapea00x/Makefile
+++ b/drivers/usb/misc/xapea00x/Makefile
@@ -4,4 +4,5 @@
 #
 obj-$(CONFIG_USB_XAPEA00X) += xapea00x.o
 
-xapea00x-y += xapea00x-core.o xapea00x-bridge.o
+xapea00x-y += xapea00x-core.o xapea00x-bridge.o xapea00x-tpm.o
+
diff --git a/drivers/usb/misc/xapea00x/xapea00x-core.c 
b/drivers/usb/misc/xapea00x/xapea00x-core.c
index ad62c40d724b..7c7acaba9da4 100644
--- a/drivers/usb/misc/xapea00x/xapea00x-core.c
+++ b/drivers/usb/misc/xapea00x/xapea00x-core.c
@@ -296,6 +296,31 @@ static void xapea00x_tpm_probe(struct work_struct *work)
struct spi_device *tpm;
int retval;
 
+   mutex_lock(>usb_mutex);
+   if (!dev->interface) {
+   retval = -ENODEV;
+   goto out;
+   }
+   /*
+* This driver is the "platform" in TPM terminology. Before
+* passing control of the TPM to the Linux TPM subsystem, do
+* the TPM initialization normally done by the platform code
+* (e.g., BIOS).
+*/
+   retval = xapea00x_tpm_platform_initialize(dev);
+   if (retval) {
+   dev_err(>interface->dev,
+   "unable to do TPM platform initialization: %d\n",
+   retval);
+   goto err;
+   }
+
+   /*
+* Now register the TPM with the Linux TPM subsystem.  This
+* may call through to xapea00x_spi_transfer_one_message(), so
+* don't hold usb_mutex here.
+*/
+   mutex_unlock(>usb_mutex);
tpm = spi_new_device(spi_master, _board_info);
mutex_lock(>usb_mutex);
if (!dev->interface) {
diff --git a/drivers/usb/misc/xapea00x/xapea00x-tpm.c 
b/drivers/usb/misc/xapea00x/xapea00x-tpm.c
new file mode 100644
index ..d0e5c5b6d75d
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/xapea00x-tpm.c
@@ -0,0 +1,954 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Driver for the XAP-EA-00x series of the Xaptum Edge Access Card, a
+ *  TPM 2.0-based hardware module for authenticating IoT devices and
+ *  gateways.
+ *
+ *  Copyright (c) 2017 Xaptum, Inc.
+ */
+
+#include "xapea00x.h"
+
+#define TPM_RETRY 50
+#define TPM_TIMEOUT   5// msecs
+#define TPM_TIMEOUT_RANGE_US  300  // usecs
+
+#define TIS_SHORT_TIMEOUT 750  // msecs
+#define TIS_LONG_TIMEOUT  2000 // msecs
+
+#define TIS_MAX_BUF   1024 // byte
+#define TIS_HEADER_LEN10   // byte
+
+#define TPM2_TIMEOUT_A750  // msecs
+#define TPM2_TIMEOUT_B2000 // msecs
+#define TPM2_TIMEOUT_C200  // msecs
+#define TPM2_TIMEOUT_D30   // msecs
+
+#define TPM_ACCESS_0  0x
+#define TPM_STS_0 0x0018
+#define TPM_DATA_FIFO_0   0x0024
+
+#define TPM2_ST_NO_SESSIONS   0x8001
+#define TPM2_ST_SESSIONS  0x8002
+
+#define TPM2_CC_STARTUP   0x0144
+#define TPM2_CC_SHUTDOWN  0x0145
+#define TPM2_CC_SELF_TEST 0x0143
+#define TPM2_CC_GET_RANDOM0x017B
+#define TPM2_CC_HIERARCHY_CHANGE_AUTH  0x0129
+#define TPM2_CC_DICT_ATTACK_LOCK_RST   0x0139
+
+#define TPM_RC_SUCCESS0x000
+#define TPM_RC_INITIALIZE 0x100
+
+enum tis_access {
+   TPM_ACCESS_VALID = 0x80,
+   TPM_ACCESS_ACTIVE_LOCALITY = 0x20,
+   TPM_ACCESS_REQUEST_PENDING = 0x04,
+   TPM_ACCESS_REQUEST_USE = 0x02
+};
+
+enum tis_status {
+   TPM_STS_VALID  = 0x80,
+   TPM_STS_COMMAND_READY  = 0x40,
+   TPM_STS_GO = 0x20,
+   TPM_STS_DATA_AVAIL = 0x10,
+   TPM_STS_DATA_EXPECT= 0x08,
+   TPM_STS_SELF_TEST_DONE = 0x04,
+   TPM_STS_RESPONSE_RETRY = 0x02
+};
+
+struct tpm_tis_command {
+   __be16 tag;
+   __be32 size;
+   __be32 c

[PATCH 1/2] usb: misc: xapea00x: add driver for Xaptum ENF Access Card

[David R. Bild]

This commit adds a driver for the Xaptum ENF Access Card, a TPM2.0
hardware module for authenticating IoT devices and gateways.

The card consists of a SPI TPM 2.0 chip and a USB-SPI bridge. This
driver configures the bridge, registers the bridge as an SPI
controller, and adds the TPM 2.0 as an SPI device.  The in-kernel TPM
2.0 driver is then automatically loaded to configure the TPM and
expose it to userspace.

Signed-off-by: David R. Bild <david.b...@xaptum.com>
---
 MAINTAINERS |   6 +
 drivers/usb/misc/Kconfig|   2 +
 drivers/usb/misc/Makefile   |   1 +
 drivers/usb/misc/xapea00x/Kconfig   |  16 ++
 drivers/usb/misc/xapea00x/Makefile  |   7 +
 drivers/usb/misc/xapea00x/xapea00x-bridge.c | 399 ++
 drivers/usb/misc/xapea00x/xapea00x-core.c   | 429 
 drivers/usb/misc/xapea00x/xapea00x-spi.c| 209 ++
 drivers/usb/misc/xapea00x/xapea00x.h|  75 +
 9 files changed, 1144 insertions(+)
 create mode 100644 drivers/usb/misc/xapea00x/Kconfig
 create mode 100644 drivers/usb/misc/xapea00x/Makefile
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-bridge.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-core.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-spi.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x.h

diff --git a/MAINTAINERS b/MAINTAINERS
index a6e86e20761e..8d16f34b8603 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14300,6 +14300,12 @@ L: linux-wirel...@vger.kernel.org
 S: Maintained
 F: drivers/net/wireless/rndis_wlan.c
 
+USB XAPEA00X DRIVER
+M: David R. Bild <david.b...@xaptum.com>
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/usb/misc/xapea00x/
+
 USB XHCI DRIVER
 M: Mathias Nyman <mathias.ny...@intel.com>
 L: linux-usb@vger.kernel.org
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 68d2f2cd17dd..747d7f03fb84 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -275,3 +275,5 @@ config USB_CHAOSKEY
 
  To compile this driver as a module, choose M here: the
  module will be called chaoskey.
+
+source "drivers/usb/misc/xapea00x/Kconfig"
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 109f54f5b9aa..f3583501547c 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -30,4 +30,5 @@ obj-$(CONFIG_USB_HSIC_USB4604)+= usb4604.o
 obj-$(CONFIG_USB_CHAOSKEY) += chaoskey.o
 
 obj-$(CONFIG_USB_SISUSBVGA)+= sisusbvga/
+obj-$(CONFIG_USB_XAPEA00X) += xapea00x/
 obj-$(CONFIG_USB_LINK_LAYER_TEST)  += lvstest.o
diff --git a/drivers/usb/misc/xapea00x/Kconfig 
b/drivers/usb/misc/xapea00x/Kconfig
new file mode 100644
index ..27e87bc1b4b2
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/Kconfig
@@ -0,0 +1,16 @@
+config  USB_XAPEA00X
+tristate "Xaptum ENF Access card support (XAP-EA-00x)"
+depends on USB_SUPPORT
+select SPI
+select TCG_TPM
+select TCG_TIS_SPI
+---help---
+  Say Y here if you want to support the Xaptum ENF Access
+  modules (XAP-EA-00x) in the USB or Mini PCI-e form
+  factors. The XAP-EA-00x module exposes a TPM 2.0 as
+  /dev/tpmX to use for authenticating with the Xaptum ENF.
+
+  To compile this driver as a module, choose M here. The
+  module will be called xapea00x.
+
+  If unsure, say M.
diff --git a/drivers/usb/misc/xapea00x/Makefile 
b/drivers/usb/misc/xapea00x/Makefile
new file mode 100644
index ..c4bcd7524c31
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for the xapea00x driver.
+#
+obj-$(CONFIG_USB_XAPEA00X) += xapea00x.o
+
+xapea00x-y += xapea00x-core.o xapea00x-bridge.o
diff --git a/drivers/usb/misc/xapea00x/xapea00x-bridge.c 
b/drivers/usb/misc/xapea00x/xapea00x-bridge.c
new file mode 100644
index ..3efa697f216a
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/xapea00x-bridge.c
@@ -0,0 +1,399 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Driver for the XAP-EA-00x series of the Xaptum Edge Access Card, a
+ *  TPM 2.0-based hardware module for authenticating IoT devices and
+ *  gateways.
+ *
+ *  Copyright (c) 2017 Xaptum, Inc.
+ */
+
+#include "xapea00x.h"
+
+#define XAPEA00X_BR_CMD_READ 0x00
+#define XAPEA00X_BR_CMD_WRITE0x01
+#define XAPEA00X_BR_CMD_WRITEREAD0x02
+
+#define XAPEA00X_BR_BREQTYP_SET  0x40
+
+#define XAPEA00X_BR_BREQ_SET_GPIO_VALUES  0x21
+#define XAPEA00X_BR_BREQ_SET_GPIO_CS 0x25
+#define XAPEA00X_BR_BREQ_SET_SPI_WORD0x31
+
+#define XAPEA00X_BR_USB_TIMEOUT  1000 // msecs
+
+#defi

[PATCH 0/2] Add driver for Xaptum ENF Access card (XAP-EA-00x)

[David R. Bild]

This series add a driver for the Xaptum ENF Access card line
(XAP-EA-00x), a series of mini PCI-e cards containing a TPM 2.0 chip
used to authenticate IoT devices and gateways.

The hardware is essentially a USB-SPI bridge and an SPI TPM 2.0
chip. The first patch registers the bridge as an SPI controller and
the TPM as an SPI device. The second patch performs the TPM platform
initialization that would normally be done by the BIOS.

David R. Bild (2):
  usb: misc: xapea00x: add driver for Xaptum ENF Access Card
  usb: misc: xapea00x: perform platform initialization of TPM

 MAINTAINERS |   6 +
 drivers/usb/misc/Kconfig|   2 +
 drivers/usb/misc/Makefile   |   1 +
 drivers/usb/misc/xapea00x/Kconfig   |  16 +
 drivers/usb/misc/xapea00x/Makefile  |   8 +
 drivers/usb/misc/xapea00x/xapea00x-bridge.c | 399 
 drivers/usb/misc/xapea00x/xapea00x-core.c   | 454 +
 drivers/usb/misc/xapea00x/xapea00x-spi.c| 209 ++
 drivers/usb/misc/xapea00x/xapea00x-tpm.c| 954 
 drivers/usb/misc/xapea00x/xapea00x.h|  75 +++
 10 files changed, 2124 insertions(+)
 create mode 100644 drivers/usb/misc/xapea00x/Kconfig
 create mode 100644 drivers/usb/misc/xapea00x/Makefile
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-bridge.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-core.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-spi.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-tpm.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x.h

-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 0/2] Add driver for Xaptum ENF Access card (XAP-EA-00x)

[David R. Bild]

On Fri, Jan 5, 2018 at 8:41 AM, Greg Kroah-Hartman
 wrote:
> I've been a "bit" busy over the past few months, and haven't had the
> chance to review new drivers like this, for obvious reasons.
>
> Don't worry, the patches aren't lost, they are still in my queue.

That's what I figured --- just making sure. Thanks.

> Wait, I don't review RFC patch series, as obviously you don't think it's
> ready to be merged :)
>
> Care to redo this without that marking, if you really think it is ready?

Gotcha - I'll resend as a patch.

Thanks,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 0/2] Add driver for Xaptum ENF Access card (XAP-EA-00x)

[David R. Bild]

On Fri, Dec 22, 2017 at 11:16 AM, David R. Bild <david.b...@xaptum.com> wrote:
>
> This series add a driver for the Xaptum ENF Access card line
> (XAP-EA-00x), a series of mini PCI-e cards containing a TPM 2.0 chip
> used to authenticate IoT devices and gateways.

Greg,

Do I need to do anything else to get this new driver queued up for
review?  Not trying to rush things --- just making sure I haven't
missed a step or submitted to the wrong place.

Thanks,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

Normally the system platform (i.e., BIOS/UEFI for x86) is responsible
for performing intialization of the TPM.  For these modules, the host
kernel is the platform, so we perform the initialization in the driver
before registering the TPM with the kernel TPM subsystem.

The initialization consists of issuing the TPM startup command,
running the TPM self-test, and setting the TPM platform hierarchy
authorization to a random, unsaved value so that it can never be used
after the driver has loaded.

Signed-off-by: David R. Bild <david.b...@xaptum.com>
---
 drivers/usb/misc/xapea00x/Makefile|   3 +-
 drivers/usb/misc/xapea00x/xapea00x-core.c |  25 +
 drivers/usb/misc/xapea00x/xapea00x-tpm.c  | 953 ++
 3 files changed, 980 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-tpm.c

diff --git a/drivers/usb/misc/xapea00x/Makefile 
b/drivers/usb/misc/xapea00x/Makefile
index c4bcd7524c31..aa3f8803cdf5 100644
--- a/drivers/usb/misc/xapea00x/Makefile
+++ b/drivers/usb/misc/xapea00x/Makefile
@@ -4,4 +4,5 @@
 #
 obj-$(CONFIG_USB_XAPEA00X) += xapea00x.o
 
-xapea00x-y += xapea00x-core.o xapea00x-bridge.o
+xapea00x-y += xapea00x-core.o xapea00x-bridge.o xapea00x-tpm.o
+
diff --git a/drivers/usb/misc/xapea00x/xapea00x-core.c 
b/drivers/usb/misc/xapea00x/xapea00x-core.c
index 04e5920fd2a1..7aa74f0957cc 100644
--- a/drivers/usb/misc/xapea00x/xapea00x-core.c
+++ b/drivers/usb/misc/xapea00x/xapea00x-core.c
@@ -296,6 +296,31 @@ static void xapea00x_tpm_probe(struct work_struct *work)
struct spi_device *tpm;
int retval;
 
+   mutex_lock(>usb_mutex);
+   if (!dev->interface) {
+   retval = -ENODEV;
+   goto out;
+   }
+   /*
+* This driver is the "platform" in TPM terminology. Before
+* passing control of the TPM to the Linux TPM subsystem, do
+* the TPM initialization normally done by the platform code
+* (e.g., BIOS).
+*/
+   retval = xapea00x_tpm_platform_initialize(dev);
+   if (retval) {
+   dev_err(>interface->dev,
+   "unable to do TPM platform initialization: %d\n",
+   retval);
+   goto err;
+   }
+
+   /*
+* Now register the TPM with the Linux TPM subsystem.  This
+* may call through to xapea00x_spi_transfer_one_message(), so
+* don't hold usb_mutex here.
+*/
+   mutex_unlock(>usb_mutex);
tpm = spi_new_device(spi_master, _board_info);
mutex_lock(>usb_mutex);
if (!dev->interface) {
diff --git a/drivers/usb/misc/xapea00x/xapea00x-tpm.c 
b/drivers/usb/misc/xapea00x/xapea00x-tpm.c
new file mode 100644
index ..d713e589619b
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/xapea00x-tpm.c
@@ -0,0 +1,953 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Driver for the XAP-EA-00x series of the Xaptum Edge Access Card, a
+ *  TPM 2.0-based hardware module for authenticating IoT devices and
+ *  gateways.
+ *
+ *  Copyright (c) 2017 Xaptum, Inc.
+ */
+
+#include "xapea00x.h"
+
+#define TPM_RETRY 50
+#define TPM_TIMEOUT   5// msecs
+#define TPM_TIMEOUT_RANGE_US  300  // usecs
+
+#define TIS_SHORT_TIMEOUT 750  // msecs
+#define TIS_LONG_TIMEOUT  2000 // msecs
+
+#define TIS_MAX_BUF   1024 // byte
+#define TIS_HEADER_LEN10   // byte
+
+#define TPM2_TIMEOUT_A750  // msecs
+#define TPM2_TIMEOUT_B2000 // msecs
+#define TPM2_TIMEOUT_C200  // msecs
+#define TPM2_TIMEOUT_D30   // msecs
+
+#define TPM_ACCESS_0  0x
+#define TPM_STS_0 0x0018
+#define TPM_DATA_FIFO_0   0x0024
+
+#define TPM2_ST_NO_SESSIONS   0x8001
+#define TPM2_ST_SESSIONS  0x8002
+
+#define TPM2_CC_STARTUP   0x0144
+#define TPM2_CC_SHUTDOWN  0x0145
+#define TPM2_CC_SELF_TEST 0x0143
+#define TPM2_CC_GET_RANDOM0x017B
+#define TPM2_CC_HIERARCHY_CHANGE_AUTH   0x0129
+#define TPM2_CC_DICTIONARY_ATTACK_LOCK_RESET 0x0139
+
+#define TPM_RC_SUCCESS0x000
+#define TPM_RC_INITIALIZE 0x100
+
+enum tis_access {
+   TPM_ACCESS_VALID = 0x80,
+   TPM_ACCESS_ACTIVE_LOCALITY = 0x20,
+   TPM_ACCESS_REQUEST_PENDING = 0x04,
+   TPM_ACCESS_REQUEST_USE = 0x02
+};
+
+enum tis_status {
+   TPM_STS_VALID  = 0x80,
+   TPM_STS_COMMAND_READY  = 0x40,
+   TPM_STS_GO = 0x20,
+   TPM_STS_DATA_AVAIL = 0x10,
+   TPM_STS_DATA_EXPECT= 0x08,
+   TPM_STS_SELF_TEST_DONE = 0x04,
+   TPM_STS_RESPONSE_RETRY = 0x02
+};
+
+struct tpm_tis_command {
+   __be16 tag;
+   __be32 size;
+   __be32 c

[RFC 1/2] usb: misc: xapea00x: add driver for Xaptum ENF Access Card

[David R. Bild]

This commit adds a driver for the Xaptum ENF Access Card, a TPM2.0
hardware module for authenticating IoT devices and gateways.

The card consists of a SPI TPM 2.0 chip and a USB-SPI bridge. This
driver configures the bridge, registers the bridge as an SPI
controller, and adds the TPM 2.0 as an SPI device.  The in-kernel TPM
2.0 driver is then automatically loaded to configure the TPM and
expose it to userspace.

Signed-off-by: David R. Bild <david.b...@xaptum.com>
---
 MAINTAINERS |   6 +
 drivers/usb/misc/Kconfig|   2 +
 drivers/usb/misc/Makefile   |   1 +
 drivers/usb/misc/xapea00x/Kconfig   |  16 ++
 drivers/usb/misc/xapea00x/Makefile  |   7 +
 drivers/usb/misc/xapea00x/xapea00x-bridge.c | 399 ++
 drivers/usb/misc/xapea00x/xapea00x-core.c   | 429 
 drivers/usb/misc/xapea00x/xapea00x-spi.c| 209 ++
 drivers/usb/misc/xapea00x/xapea00x.h|  75 +
 9 files changed, 1144 insertions(+)
 create mode 100644 drivers/usb/misc/xapea00x/Kconfig
 create mode 100644 drivers/usb/misc/xapea00x/Makefile
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-bridge.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-core.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-spi.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x.h

diff --git a/MAINTAINERS b/MAINTAINERS
index a6e86e20761e..8d16f34b8603 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14300,6 +14300,12 @@ L: linux-wirel...@vger.kernel.org
 S: Maintained
 F: drivers/net/wireless/rndis_wlan.c
 
+USB XAPEA00X DRIVER
+M: David R. Bild <david.b...@xaptum.com>
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/usb/misc/xapea00x/
+
 USB XHCI DRIVER
 M: Mathias Nyman <mathias.ny...@intel.com>
 L: linux-usb@vger.kernel.org
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 68d2f2cd17dd..747d7f03fb84 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -275,3 +275,5 @@ config USB_CHAOSKEY
 
  To compile this driver as a module, choose M here: the
  module will be called chaoskey.
+
+source "drivers/usb/misc/xapea00x/Kconfig"
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 109f54f5b9aa..f3583501547c 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -30,4 +30,5 @@ obj-$(CONFIG_USB_HSIC_USB4604)+= usb4604.o
 obj-$(CONFIG_USB_CHAOSKEY) += chaoskey.o
 
 obj-$(CONFIG_USB_SISUSBVGA)+= sisusbvga/
+obj-$(CONFIG_USB_XAPEA00X) += xapea00x/
 obj-$(CONFIG_USB_LINK_LAYER_TEST)  += lvstest.o
diff --git a/drivers/usb/misc/xapea00x/Kconfig 
b/drivers/usb/misc/xapea00x/Kconfig
new file mode 100644
index ..27e87bc1b4b2
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/Kconfig
@@ -0,0 +1,16 @@
+config  USB_XAPEA00X
+tristate "Xaptum ENF Access card support (XAP-EA-00x)"
+depends on USB_SUPPORT
+select SPI
+select TCG_TPM
+select TCG_TIS_SPI
+---help---
+  Say Y here if you want to support the Xaptum ENF Access
+  modules (XAP-EA-00x) in the USB or Mini PCI-e form
+  factors. The XAP-EA-00x module exposes a TPM 2.0 as
+  /dev/tpmX to use for authenticating with the Xaptum ENF.
+
+  To compile this driver as a module, choose M here. The
+  module will be called xapea00x.
+
+  If unsure, say M.
diff --git a/drivers/usb/misc/xapea00x/Makefile 
b/drivers/usb/misc/xapea00x/Makefile
new file mode 100644
index ..c4bcd7524c31
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for the xapea00x driver.
+#
+obj-$(CONFIG_USB_XAPEA00X) += xapea00x.o
+
+xapea00x-y += xapea00x-core.o xapea00x-bridge.o
diff --git a/drivers/usb/misc/xapea00x/xapea00x-bridge.c 
b/drivers/usb/misc/xapea00x/xapea00x-bridge.c
new file mode 100644
index ..2dc077b16547
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/xapea00x-bridge.c
@@ -0,0 +1,399 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Driver for the XAP-EA-00x series of the Xaptum Edge Access Card, a
+ *  TPM 2.0-based hardware module for authenticating IoT devices and
+ *  gateways.
+ *
+ *  Copyright (c) 2017 Xaptum, Inc.
+ */
+
+#include "xapea00x.h"
+
+#define XAPEA00X_BR_CMD_READ 0x00
+#define XAPEA00X_BR_CMD_WRITE0x01
+#define XAPEA00X_BR_CMD_WRITEREAD0x02
+
+#define XAPEA00X_BR_BREQTYP_SET  0x40
+
+#define XAPEA00X_BR_BREQ_SET_GPIO_VALUES  0x21
+#define XAPEA00X_BR_BREQ_SET_GPIO_CS 0x25
+#define XAPEA00X_BR_BREQ_SET_SPI_WORD0x31
+
+#define XAPEA00X_BR_USB_TIMEOUT  1000 // msecs
+
+#defi

[RFC 0/2] Add driver for Xaptum ENF Access card (XAP-EA-00x)

[David R. Bild]

This series add a driver for the Xaptum ENF Access card line
(XAP-EA-00x), a series of mini PCI-e cards containing a TPM 2.0 chip
used to authenticate IoT devices and gateways.

The hardware is essentially a USB-SPI bridge and an SPI TPM 2.0
chip. The first patch registers the bridge as an SPI controller and
the TPM as an SPI device. The second patch performs the TPM platform
initialization that would normally be done by the BIOS.

David R. Bild (2):
  usb: misc: xapea00x: add driver for Xaptum ENF Access Card
  usb: misc: xapea00x: perform platform initialization of TPM

 MAINTAINERS |   6 +
 drivers/usb/misc/Kconfig|   2 +
 drivers/usb/misc/Makefile   |   1 +
 drivers/usb/misc/xapea00x/Kconfig   |  16 +
 drivers/usb/misc/xapea00x/Makefile  |   8 +
 drivers/usb/misc/xapea00x/xapea00x-bridge.c | 399 
 drivers/usb/misc/xapea00x/xapea00x-core.c   | 454 +
 drivers/usb/misc/xapea00x/xapea00x-spi.c| 209 ++
 drivers/usb/misc/xapea00x/xapea00x-tpm.c| 953 
 drivers/usb/misc/xapea00x/xapea00x.h|  75 +++
 10 files changed, 2123 insertions(+)
 create mode 100644 drivers/usb/misc/xapea00x/Kconfig
 create mode 100644 drivers/usb/misc/xapea00x/Makefile
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-bridge.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-core.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-spi.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-tpm.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x.h

-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html