On Mon, Nov 19, 2018 at 02:36:28PM -0800, James Bottomley wrote:

On Mon, 2018-11-19 at 14:44 -0700, Jason Gunthorpe wrote:

quoted

On Mon, Nov 19, 2018 at 01:34:41PM -0800, James Bottomley wrote:

quoted

On Mon, 2018-11-19 at 14:19 -0700, Jason Gunthorpe wrote:
[...]

quoted

Sure, for stuff working with shared secrets, etc, this make
sense. But PCR extends are not secret, so there is no reason to
encrypt them on the bus.

OK, there's a miscommunication here.  I believe the current
document states twice that there's no encryption for PCR
operations.  We merely use a salted HMAC session to ensure that
they're reliably received by the TPM and not altered in-flight.

Sure, but again, what is this preventing?

It prevents the interposer having free reign to set the PCR values by
substituting every measurement you send to the TPM.  

But the threat model for PCR excludes the possibility of an
interposer. If you have an interposer the PCB is broken and all PCR
security is already lost.

some scope for detecting the presence of an interposer if it does try
to tamper with your measurements.

But I can still tamper with them.. I can have the interposer
delete/fail the kernel PCR commands and issue un-hashed ones.

The kernel would have to do something extreme like fault the TPM and
totally disable the linux device if any PCR extend fails. That should
probably be included in the plan?

tamper, like there is for confidentiality of sealed data and random
numbers, but it seems to be an improvement on what's currently there
given that we have to install the session machinery for
encryption/decryption anyway.

Sure, if you have the machinery and it can be used at PCR time, then
why not use it.. But I think any description about why this is being
done should be clear about what the threat model is for PCR. 

I'm mostly concerned about how the document was written which makes it
seems like security of extend beyond what is integral to the
PCB/chipset is meaningful, considering the threat model PCR is based
on.

We don't want people to become confused and think they are getting
more security than there really is.

quoted

If you accept that PCB trust is essential for PCR security, then I
think trusting the PCB to deliver the PCR extends is perfectly fine.

The *current* interposer is a hardware device on the bus.  The next gen
is reported to be more software based.

Well, that is terrifying.

But a SW based attack that can toggle TPM reset or alter TPM commands
in flight getting very much into the 'chips are broken' territory
where the chain of trust required for PCR is broken. This is breaking
fundamental assumptions of the threat model here :(

It is hard to know if more crypto could really prevent problems
without knowing the details of how this is being done??

Jason