Currently, IMA would invalidate a PCR bank corresponding to an unsupported
hash algorithm by extending it with 0xfe ... fe exactly once.
The idea is, that banks corresponding to such algorithms would be readily
recognizable by comparing against HASH(0x00 ... 00 | fe ... fe), i.e. the
value they'd
As it currently stands, IMA would invalidate a PCR bank corresponding to
an unsupported hash algorithm over and over again by extending it with
0xfe ... fe for each measurement list entry recorded (for
CONFIG_IMA_COMPAT_FALLBACK_TPM_EXTEND=n).
This however, makes the problem of deciding from the P
Upon recognizing previously unmaintained PCR banks at __init after kexec,
a subsequent commit will make IMA to disable the corresponding hashes
for the current boot as well.
For this, access to ima_free_tfm() from outside its compilation unit is
needed. Make its linkage extern.
Signed-off-by: Nic
Normally IMA would extend a template hash of each bank's associated
algorithm into a PCR. However, if a bank's hash algorithm is unavailable
to the kernel at IMA init time, it would fallback to extending padded SHA1
hashes instead.
That is, if e.g. SHA-256 was missing at IMA init, it would extend
For CONFIG_IMA_COMPAT_FALLBACK_TPM_EXTEND=n, SHA-1 is not a hard
requirement anymore. Make ima_init_crypto() continue on SHA-1
instantiation errors.
Note that the configured ima_hash must still be available. If that
happened to be set to SHA-1 and SHA-1 was missing, then IMA would
still fail to in
The existing tpm_pcr_extend() extends all of a PCR's allocated banks with
the corresponding digest from the provided digests[] argument.
An upcoming code change to IMA will introduce the need to skip over those
banks it does not have a hash algorithm implementation available for.
Introduce tpm_pc
runtime_measurements_ sysfs files are getting created for
each PCR bank + for SHA-1.
Now that runtime_measurements_ sysfs file creation is being
skipped for unsupported hash algorithms, it will become possible that no
such file would be provided at all once SHA-1 is made optional in a
later patch.
Make the INVALID_PCR() #define available to other compilation units
by moving it from ima_policy.c to ima.h and renaming it to
IMA_INVALID_PCR() in the course.
Signed-off-by: Nicolai Stange
---
security/integrity/ima/ima.h| 4
security/integrity/ima/ima_policy.c | 5 +
2 files c
Hi,
this is v2 of the RFC series to disentangle IMA from its current
dependency on a working SHA-1 implementation.
For reference, v1 can be found at [1].
Several options for when and how to invalidate unsupported TPM PCR banks
by extending them with a unique constant had been discussed at the v1
Since recently, IMA would not record measurement list entries into PCR
banks for which it doesn't have a corresponding in-kernel hash algorithm
implementation available anymore (for
CONFIG_IMA_COMPAT_FALLBACK_TPM_EXTEND=n).
With TPM 2.0, the only hash algorithms guaranteed to be implemented on a
T
PCR reads aren't currently authenticated even with CONFIG_TCG_TPM2_HMAC=y
yet.
It is probably desirable though, as e.g. IMA does some PCR reads to form
the cumulative boot digest subsequently extended into PCR 10 (an operation
which *is* authenticated).
Furthermore, a subsequent patch will make I
Mimi Zohar writes:
> On Tue, 2025-03-18 at 16:55 +0100, Nicolai Stange wrote:
>> Mimi Zohar writes:
>> > FYI, because the IMA Kconfig selects SHA1, we're guaranteed that SHA1
>> > exists in
>> > the kernel and the subsequent kexec'ed kernel. For this reason we're
>> > guaranteed
>> > that the
At the current stage, IMA would invalidate PCR banks corresponding to
unsupported hash algorithms exactly once by extending with the special
0xfe ... fe from each kernel in a kexec chain.
In order to work towards the goal of doing that only once for the
overall chain, subsequent kernels must be ab
13 matches
Mail list logo
