Enable measured launch of docked laptops

Description

PCR measurements may vary on the same device between docked and undocked configurations.

Environment

None

Validation Steps

None

Activity

Show:
Rich Persaud
May 2, 2019, 6:44 PM
Edited
  • We need a release note to document when a quirk has been added to support a specific dock/laptop.

  • Do we need a release note that explains how/when to modify OpenXT quirk configuration to support a new dock?

From Github discussion:

From :

I foresee this growing to a large list of quirks over time. Would it make more sense to make an install/answerfile option to include or exclude PCR1? This should be accompanied with some sort of disclaimer citing what the security implications of ignoring PCR1 are to the overall trust of the system.

USB/PCR1 issue is fairly ubiquitous in KBL+ systems. This can be seen by adding/removing drives or even changing where a keyboard/mouse are plugged in on a system. It is very annoying and we are pushing for it to get changed.

From

... if you don't measure PCR1, you can't really guarantee anymore that the hardware/firmware haven't been tampered with, which pretty much means all bets are off... Unless you know exactly what's measured into PCR1, and it happens to not be anything important.
That being said, it's useful to be able to exclude PCR1, but I agree with @pearsonk that the user should be made aware of it, or even have the ability to decide whether or not to include it.

Jason Andryuk
May 3, 2019, 5:50 PM

This has become a low priority for me, so I am not actively working on it.

First an aside about PCR1. PCR1 is supposed to be just the data/data associated with the code in PCR0. From: https://www.trustedcomputinggroup.org/wp-content/uploads/PC-ClientPlatform_Profile_for_TPM_2p0_Systems_v49_161114_public-review.pdf

PCR[1] –Host Platform Configuration

Information about the configuration of the PC Motherboard including hardware components and how they are configured is measured to PCR[1].In general, measure into PCR[1] the data that is associated with the code that has been measured into PCR[0].

Granted, that relies on the firmware following the spec which is not something firmware developers like to do.

Options:

  • Default enable all quirks

    • Just run then all the time

  • Answerfile enable all quirks

    • All or nothing control of running all quirks

  • Answerfile enable selected quirks

    • Control which particular quirks are run

  • Specify the PCR selection in the answerfile

    • Let the installer/answerfile define the PCR selection

A PCR selection in the answerfile could be combined with quirk control.

There are trade-offs to each.

The installer, on upgrade, will blindly call write_config_pcrs which will overwrite /config/config.pcrs with the default selection. This will blow away any quirks and needs to be re-worked to handle quirks if desired.

Also on upgrade, there isn't an answerfile, so control over quirks would need to persist somehow. You could revert to only allow installation time PCR selection, but I think there is value in having the ability to change the PCR selection during an OTA.

Assignee

Jason Andryuk

Reporter

Rich Persaud

Labels

None

QA Assignee

None

QA Image URL

None

Components

Fix versions

Affects versions

Priority

Major
Configure