On 11/2/24 12:04, James Bottomley wrote:
On Sat, 2024-11-02 at 10:53 -0400, Daniel P. Smith wrote:
Hi Luto,
My apologies, I missed this response and the active on v11 cause me
to
get an inquiry why I hadn't responded.
On 9/21/24 18:40, Andy Lutomirski wrote:
[...]
I assumed that "deliberately cap" meant that there was an actual
feature where you write something to the event log (if applicable)
and extend the PCR in a special way that *turns that PCR off*.
That is, it does something such that later-loaded software *can't*
use that PCR to attest or unseal anything, etc.
But it sounds like you're saying that no such feature exists. And
a quick skim of the specs doesn't come up with anything. And the
SHA1 banks may well be susceptible to a collision attack.
Correct, the only entity that can disable PCR banks is the firmware.
No, that's not correct. Any user can use TPM_PCR_Allocate to activate
or deactivate individual banks. The caveat is the change is not
implemented until the next TPM reset (which should involve a reboot).
BIOS also gets to the TPM before the kernel does, so it can, in theory,
check what banks a TPM has and call TPM_PCR_Allocate to change them.
In practice, because this requires a reboot, this is usually only done
from the BIOS menus not on a direct boot ... so you can be reasonably
sure that whatever changes were made will stick.
Okay, since there is a desire for exactness. Any system software can
send the TPM_PCR_Allocate command, specifying which PCRs should be
activated on next _TPM_init. There are restrictions such that if
DRTM_PCR is defined, then at least one bank must have a D-RTM PCR
allocation. In agreement with my statement, this is the mechanism used
by firmware to select the banks. Depending on the firmware
implementation, the firmware request will likely override the request
sent by the system software.
This brings us back to an earlier point, if one disables the SHA1 banks
in BIOS menu, then TXT will not use them and thus neither will Secure
Launch. Secure Launch will only use the algorithms used by the CPU and
the ACM.
When it initializes the TPM, it can disable banks/algorithms. After
that, when an extend operation is done, the TPM is expecting an entry
for all active PCR banks and the TPM itself does the extend hash that
is stored into the PCRs.
This, also, is not quite correct: an extend is allowed to specify banks
that don't exist (in which case nothing happens and no error is
reported) and miss banks that do (in which case no extend is done to
that bank). In the early days of TPM2, some BIOS implementations only
extended sha1 for instance, meaning the sha256 banks were all zero when
the kernel started.
Even today, if you activate a bank the BIOS doesn't know about, it
likely won't extend it. You can see this in VM boots with OVMF and
software TPMs having esoteric banks like SM3.
Let me correct myself here and again be extremely precise. When an
extend operation is done, the TPM driver expects to receive an array of
digests that is the same size as the number of allocated/active banks.
Specifically, it loops from 0 to chip->nr_allocated_banks, filling
TPML_DIGEST_VALUES with an entry for all the active banks, to include
SHA1 if it is active. Coming back to my response to Luto, we can either
populate it with 0 or a well-known value for each extend we send.
Regardless of what the value is, the TPM will use its implementation of
SHA1 to calculate the resulting extend value.
Even with these clarifications, the conclusion does not change. If the
firmware enables SHA1, there is nothing that can be done to disable or
block its usage from the user. Linux Secure Launch sending measurements
to all the banks that the hardware used to start the DRTM chain does not
create a vulnerability in and of itself. The user is free to leverage
the SHA1 bank in any of the TPM's Integrity Collection suite of
operations, regardless of what Secure Launch sends for the SHA1 hash.
Whereas, neutering the solution of SHA1 breaks the ability for it to
support any hardware that has a TPM1.2, of which there are still many in
use.
V/r,
Daniel P. Smith
