"Kevin O'Connor" kevin@koconnor.net wrote on 01/06/2016 12:47:29 PM:
On Wed, Jan 06, 2016 at 11:55:19AM -0500, Stefan Berger wrote:
"Kevin O'Connor" kevin@koconnor.net wrote on 01/05/2016 11:03:00 PM:
On Tue, Jan 05, 2016 at 10:07:54PM -0500, Stefan Berger wrote:
"Kevin O'Connor" kevin@koconnor.net wrote on 01/05/2016 08:55:51
PM:
Then it sounds like the only time we need to call
tpm_set_failure is
on a failure of a TPM_ORD_Extend command. It might also make
sense
to
deactivate the TPM if we detect the hardware but don't have the
acpi
tables present.
I would also deactivate it if it returned an error to TPM_ORD_Startup, TPM_ORD_SelfTestFull. Since the menu is written
in
such a way that the user only has the choices that are valid for
the
current state, also those commands have to work, unless the TPM is defective. Or is that too strict?
Attempting to deactivate if TPM_ORD_Startup or TPM_ORD_SelfTestFull fail makes sense.
I wonder if the code could attempt to assert physical presence in tpm_startup() and only enable the tpm menu if that succeeds.
There are two ways to assert physical presence, one is via software,
the
other via hardware.
I should have said, "I wonder if the code could check if software physical presence has been enabled in tpm_startup() and only enable the tpm menu if that succeeds". That is, could we issue a
I understood it that way.
TPM_ORD_PhysicalPresence(NOT_PRESENT) and if it succeeds then we enable the menu and make sure we always issue a LOCK before booting.
What I am doing now in assert_physical_presence is to check whether physical presence has already been asserted and return 0, check whether HW physical presence has been asserted and return 0, if SW assertion has been disabled return -1, otherwise try to do SW assertion.
We need to issue TPM_ORD_PhysicalPresence(PRESENT) to assert SW pp and TPM_ORD_PhysicalPresence(NOT_PRESENT + LOCK) in tpm_prepboot.
tpm_prepboot actually needs to be further adapted for the case of HW pp. Probably it is not necessary to send the CMD_ENABLE in any case. I forgot about that in the patches I sent.
If the command fails then the code assumes it has no requirements wrt physical presence.
If that's too restrictive, could the startup code query if either CMD_ENABLE has already been set or if LifetimeLock has not been set?
Have a look at the patch I sent. I think this correct extends to assert_physical_presence function with making sure that SW pp is asserted or HW pp is asserted through other means.
For hardware assertion there's a PIN on the chip that indicates the state of a dip switch for example. Problem is, this assertion cannot easily be read as a flag. We have to infer this via a command. So the trick seems to be to send TPM_PhysicalEnable/TPM_PhysicalDisable with the value that's already there.
Is there any BIOS requirements when hardware physical presence is in use though? If the hardware physical presence is set, then the BIOS can't limit the owner/activate/enable commands. So, why bother with the tpm menu - the user could just administer those settings from the OS.
In my opinion HW pp should also allow the menu to be presented so that users do not need different tools in OS that normally are not available due to SW pp. Though no command seems to be able to overrid the HW physical presence.
Stefan
-Kevin