Re: [GRUB PATCH RFC 00/18] i386: Intel TXT secure launcher

[Daniel P. Smith]

On 5/7/20 7:06 AM, Daniel Kiper wrote:
> Hi Åukasz,
> 
> On Tue, May 05, 2020 at 04:38:02PM +0200, Lukasz Hawrylko wrote:
>> On Tue, 2020-05-05 at 01:21 +0200, Daniel Kiper wrote:

...

>> In OS-MLE table there is a buffer for TPM event log, however I see that
>> you are not using it, but instead allocate space somewhere in the
> 
> I think that this part requires more discussion. In my opinion we should
> have this region dynamically allocated because it gives us more flexibility.
> Of course there is a question about the size of this buffer too. I am
> not sure about that because I have not checked yet how many log entries
> are created by the SINIT ACM. Though probably it should not be large...
> 
>> memory. I am just wondering if, from security perspective, it will be
>> better to use memory from TXT heap for event log, like we do in TBOOT.
> 
> Appendix F, TPM Event Log, has following sentence: There are no
> requirements for event log to be in DMA protected memory â SINIT will
> not enforce it.
> 
> I was thinking about it and it seems to me that the TPM event log does
> not require any special protections. Any changes in it can be quickly
> detected by comparing hashes with the TPM PCRs. Does not it?
> 

I think it would be beneficial to consider the following in deciding
where the log is placed. There are two areas of attack/manipulation that
need to be considered. The first area is the log contents itself, which
as Daniel has pointed out, the log contents do not really need to be
protected from tampering as that would/should be detected during
verification by the attestor. The second area that we need to consider
is the log descriptors themselves. If these are in an area that can be
manipulated, it is an opportunity for an attacker to attempt to
influence the ACM's execution. For a little perspective, the ACM
executes from CRAM to take the most possible precaution to ensure that
it cannot be tampered with during execution. This is very important
since it runs a CPU mode (ACM Mode) that I would consider to be higher
(or lower depending on how you view it) than SMM. As a result, the txt
heap is also included in what is mapped into CRAM. If the event log is
place in the heap, this ensures that the ACM is not using memory outside
of CRAM during execution. Now as Daniel has pointed out, the down side
to this is that it greatly restricts the log size and can only be
managed by a combination of limiting the number of events and
restricting what content is carried in the event data field.

With everything that has been said, I am wondering if it would it be
possible to make it configurable. Thoughts?

V/r,
DPS