Ensure PcrSelectionList retains order

[puiterwijk]

PcrSelectionList would (possibly) reorder and merge the different
TPML_PCR_SELECTION entries.
This is not valid in the case where for example the PcrSelectionList is
the result of a pcr_read() call: in that case, the actual PCR values are
in the same order as the TPML_PRC_SELECTION entries.
This means that "subtracting" a PcrSelectionList becomes practically
impossible.

Signed-off-by: Patrick Uiterwijk patrick@puiterwijk.org

[puiterwijk]

This was causing bugs with attestation where we have two PcrSelection's (one sha256 with some slots, and one sha1 with a slot, due to... reasons).
After parsing the TPML_PCR_SELECTION_LIST to PcrSelectionList and then back for actual transmission, the order would be switched, which caused the receiving side to misinterpret the PcrData fields.

I considered just always serializing sha1 and then sha256, but the ordering of that is up to the TPM, and is arbitrary.
This is the only way that we can ensure that this won't cause issues.

The PcrSelectionListBuilder still uses the HashMap, because the ordering for that doesn't really matter, and that can merge things into as few Selection's as possible without problems.

(I have another PcrData patch inbound tomorrow that will replace its BTreeMap with a Vec<(PcrSlot, PcrValue)>, because the same problem is at risk of happening with that object.)

[ionut-arm]

Looks good to me, but I'm not particularly knowledgeable around this part of the specs. Will let @Superhepper taken a better look.

[ionut-arm]

Oh, also, this breaks API compatibility, so it'd have to be released in version 6.0.0

[puiterwijk]

I can try to re-add a subtract function to undo the API compatibility, although the semantics of that are... a bit vague in that case.

[Superhepper]

I am not against this in any way. Though I intended the subtracting method to be used when you were using a selection that was greater then could be read in one go so you easily could find what selection you needed to use next in order to get the rest.

I am not sure if it is an actual case that will happen that often. But if would be nice to have similar convenience function or method some where. But then one needs to figure out how to implement it correctly in order to make play well together with context functions like quote.

[puiterwijk]

@Superhepper Hah! I had not even realized that that's what this was used for, that explains why I recently felt like I was reimplementing this! (I had to do exactly the "reading more than 8 PCRs" usecase the other day).

I'll send a new patch later today that brings back subtract and does the best it can.

[hug-dev]

Hello!
Just passing by to give a kind notice that we are planning to make a new release (6.0.0 I think since there were breaking changes), in around 10 days (in case you would like this PR in).

[ionut-arm]

I'm wondering if we could merge this as is, make a new release, and then bring back subtract in a minor release when the implementation is ready. Would that work for you, @Superhepper, @puiterwijk ?

[Superhepper]

Yeah that is absolutely fine with me.

[hug-dev]

Your commit was merged in #243 so that we can go ahead with the release, feel free to add the substract method in a new PR!