On 10/22/21 8:40 AM, James Bottomley wrote:
On Fri, 2021-10-22 at 07:57 -0400, Stefan Berger wrote:
On 10/22/21 7:49 AM, James Bottomley wrote:
On Fri, 2021-10-22 at 06:50 -0400, Stefan Berger wrote:
[...]
I see this also but when I get into Linux and run tpm2_pcrread I
see the SHA1 bank active but not having received any PCR
extensions from the firmware, which is not supposed to happen.
That's not entirely correct: the TCG firmware profile just requires
us to log through at least one bank; it doesn't require that all
active banks be logged. I've got several physical systems with
three active banks but only one or two measured through.
The problem with this is that you can then fake measured boot on
that system using it's unused SHA1 bank and extend into it whatever
you want and create a fake log along with it and the quote is going
to look alright.
I don't think you can. The measured boot PCRs in unused banks should
always be their default values and the measurement software should
check for this. So on a system that only uses the sha256 bank, the
sha1 bank PCR0-7 should be all zeros ... if they aren't this should be
a measurement failure.
That means that if you try to replace the sha256 agile log with one
containing fake sha1 entries, the attestation still fails because the
sha256 bank doesn't have default entries.
You can still pretend that your system only has an active SHA1 bank and
serve the fake log. Which part would raise suspicion about that on the
side that looks at that trusted boot log, SHA1 PCR 0-7 state, and quote
then?
So I think you should drop this patch and I'll change the set
of active PCR banks on the swtpm_setup level.
Even if the firmware deactivated the sha1 bank, the kernel
expectation problem is still going to exist.
Is that older Linux kernels or which part still requires sha1? A
pointer would be good. I would have to revert the change to not
activat ethe SHA1 bank from swtpm_setup if that's going to create
headaches. I thought some hardware TPM 2's today are only providing a
SHA256 bank and so it shouldn't be a problem.
The problem is IMA: it's hash is a kernel config parameter which
defaults to sha1. It then tries to calculate the boot aggregate over
the configured hash bank and doesn't check if it's unused.
What IMA should probably be doing is working out which bank the bios is
logging through and using that as the hash instead of having it as a
Kconfig parameter.
I think IMA is doing the right thing and extending into SHA1 and SHA256
PCRs if the banks are active and with the boot aggregate puts a lid on
top of the PCRs 0-7(,8-9). IMA may help raise the suspicion about abuse
of an unused PCR bank by the firmware but looking at the measured boot
log etc. alone I think is not enough.
At least a test with a recent kernel seems to work out alright when only
the SHA256 bank is active.
Stefan
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#82521): https://edk2.groups.io/g/devel/message/82521
Mute This Topic: https://groups.io/mt/86487987/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
