On Fri, May 04, 2018 at 03:19:21PM -0500, David R. Bild wrote: > 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 This would probably make more sense, I'm not opposed at least > 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.) Sounds like a much better approach to me. Jason
