[PATCH] - TPM device driver layer (tpm.c|h)

From: Richard MUSIL
Date: Thu Aug 23 2007 - 05:11:48 EST


Dear all,

I am currently writing virtual TPM device driver. This driver exposes
itself and behaves like regular TPM device (i.e. uses TPM layer which is
already present in kernel), but instead of talking to hardware it talks
to user space.

In my setup, I can create several virtual devices and delete them in
runtime. During this I noticed that current implementation is prone to
segfault when tpm_remove_hardware is called while the device is in its
receiving routine.

The problem is in tpm_remove_hardware which does all necessary steps to
remove the device, but it does not wait for the device being actually
removed and kfrees tpm_chip struct right away. If the device is at this
time in its receiving routine (through read call, for example) it blocks
the device removal until the call is completed. The call cannot be
completed though because tpm_chip struct was already kfreed.

Since there is significant timeout and it is possible to meet that
timeout in normal operation this situation is quite easily reproducible.

What I present below is rather quickfix with least impact on other TPM
parts (drivers). The patch uses device->remove callback (of
platform_device device) and reroutes this to itself. In this
callback it eventually calls vendor callback and finally kfrees all
memory resources allocated on its own.

The correct solution for this I believe would require removing TPM
hardware (as it is done by tpm_remove_hardware right now) in two steps
both called by vendor driver. In the first one vendor driver will just
"unregister" the hardware. In the second step vendor driver will call
tpm_release_resources routine which kfrees all resources allocated by
tpm.c. In order to be able to call tpm_release_resources, vendor driver
will have to register as platform driver and handle
platform_driver.probe and platform_driver.remove.

This will however require some changes in all drivers, which I cannot
test (but I could eventually write the patch). Also I see some "issues"
in tpm_tis which will have to be clarified.

--
Richard