On Fri, May 4, 2018 at 2:56 PM, David R. Bild <david.bild@xxxxxxxxxx> 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
