[U-Boot] [PATCH 3/3] lib: tpm: Add command to list resources

Simon Glass sjg at chromium.org
Mon Mar 27 02:27:25 UTC 2017


On 24 March 2017 at 03:54, Mario Six <mario.six at gdsys.cc> wrote:
> On Wed, Mar 22, 2017 at 2:05 PM, Simon Glass <sjg at chromium.org> wrote:
>> On 20 March 2017 at 03:28, Mario Six <mario.six at gdsys.cc> wrote:
>>> It is sometimes convenient to know how many and/or which resources are
>>> currently loaded into a TPG, e.g. to test is a flush operation succeeded.
>>>
>>> Hence, we add a command that lists the resources of a given type currently
>>> loaded into the TPM.
>>>
>>> Signed-off-by: Mario Six <mario.six at gdsys.cc>
>>> ---
>>>  cmd/tpm.c           | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
>>>  drivers/tpm/Kconfig |  7 +++++
>>>  2 files changed, 82 insertions(+), 1 deletion(-)
>>
>> Reviewed-by: Simon Glass <sjg at chromium.org>
>>
>> Again I wonder if we need the CONFIG.
>>
>
> Thanks for the review!
>
> As for the CONFIG option, well, there is the trivial symmetry reason that the
> flush command is deactivatable, so this should be too (since they are,
> essentially, complementary functions, one view, one deletion).
>
> Also, the list function is really more of a debug tool than a function that
> should be in a production environment.
>
> And, the most important reason why I think the CONFIG is justified is this:
> should a embedded device with a TPM that's using U-Boot as a boot loader be
> subjected to a security evaluation (e.g. Common Criteria), an evaluator might
> ask why a function like this, which, essentially has no real purpose aside from
> providing debug information, is part of the TOE (especially if the TPM is used
> as a fundamental security mechanism in the design). It enables an attacker that
> gains access to the U-Boot console to, for example, read the handles of the
> keys stored in the TPM, which is already one part of the data needed to access
> them. Granted, it's not a huge advantage, but the best answer you can give an
> evaluator is always "That's not possible" :-).
>
> So, from a user perspective, I think it's desirable to have to option to
> deactivate this function.

OK well I'm OK with it.

>
> Best regards,
>
> Mario

Applied to u-boot-dm, thanks!


More information about the U-Boot mailing list