Re: [PATCH 4/4] Improve handling of TPM2 event logs

[Petr Vandrovec <petr-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>]

Jarkko Sakkinen wrote:
> On Wed, Mar 29, 2017 at 12:43:30AM -0700, Petr Vandrovec wrote:
>> From: Petr Vandrovec<petr-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
>>
>> When TPM2 log has entries with more than 3 digests, or with digests
>> not listed in the log header, log gets misparsed, eventually
>> leading to kernel complaint that code tried to vmalloc 512MB of
>> memory (I have no idea what would happen on bigger system).
>
> It would be easier to follow this if you would give a concrete
> example of such situation. Since you are contributing this, you
> must must have bumped into this, haven't you?

Yes.  Our firmware reports TPM2 log with 4 digests (SHA1, SHA256, 
SHA384, SHA512).  Current code in kernel skips over first 3 digests 
only, trying to parse 4th digest as event length, coming to conclusion 
that entry is hundred of megabytes or few gigabytes long, and then 
failing to vmalloc() that amount of memory.

You can find parsed textual log at 
https://drive.google.com/open?id=0B7WL11GSMhrQRDBLWjc3bEZQTEk (192KB), 
and binary log at 
https://drive.google.com/open?id=0B7WL11GSMhrQQ1RCMmRmM2paR3c (48KB).

I hit situation with malformed event log on my Dell laptop - after TPM 
firmware got updated from 1.2 to 2.0, chip & everything is reported as 
TPM2, except that log stays in TPM1.2 format.


>> So code should not parse only first 3 digests: both event header
>> and event itself are already in memory, so we can parse any number
>> of digests, as long as we do not try to parse whole memory when
>> given count of 0xFFFFFFFF.
>>
>> So this change:
>>
>> * Rejects event entry with more digests than log header describes.
>>    Digest types should be unique, and all should be described in
>>    log header, so there cannot be more digests in the event than in
>>    the header.
>>
>> * Reject event entry with digest that is not described in the
>>    log header.  In theory code could hardcode information about
>>    digest IDs already assigned by TCG, but if firmware authors
>>    cannot get event log format right, why should anyone believe
>>    that they got event log content right.
>
>
> I have to say that I really didn't what this change is doing after
> reading these. I only undestood what this commit is doing by reading
> the code change.
>
> So we have a constant for banks and you are reading the number of banks
> from the event to make it more dynamic? Why it requires such a complicated
> explanation? And what is your short summary trying to say?

My short summary is trying to say that there is no reason to restrict 
parsing to only 3 digests (static number of banks), as long as we 
validate that log is logically consistent.
								Petr


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot