Re: [PATCH 0/6] Measuring TPM update counter in IMA

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 8/1/23 14:19, Tushar Sugandhi wrote:
Entries in IMA log may be lost due to code bugs, certain error conditions

I hope we don't have such bugs. And I guess the most critical ones would be
between logging and PCR extensions

being met etc.  This can result in TPM PCRs getting out of sync with the
IMA log.  One such example is events between kexec 'load' and kexec
'execute' getting lost from the IMA log when the system soft-boots into
the new Kernel using kexec[1].  The remote attestation service does not

Though this particular condition I thought would go away with your kexec series.

The other conditions would be an out-of-memory or TPM failure. The OOM would
probably be more critical since something that was supposed to be logged
couldn't be logged and now you cannot show this anymore and presumably not even
an error condition could be logged.

https://elixir.bootlin.com/linux/latest/source/security/integrity/ima/ima_queue.c#L179

have any information if the PCR mismatch with IMA log is because of loss
of entries in the IMA log or something else.  TPM 2.0 provides an update
counter which is incremented each time a PCR is updated [2]. Measuring the
TPM PCR update counter in IMA subsystem will help the remote attestation
service to validate if there are any missing entries in the IMA log, when



the system goes through certain important state changes (e.g. kexec soft
boot, IMA log snapshotting etc.)

This patch series provides the required functionality to measure the
update counter through IMA subsystem by -
  - introducing a function to retrieve PCR update counter in the TPM
    subsystem.
  - IMA functionality to acquire the update counter from the TPM subsystem.
  - Measuring the update counter at system boot and at kexec Kernel
    load.

Then the bugs you mentioned above that may happen between system boot and kexec
load are still going to confuse anyone looking at the log and quote. I don't
think you should mention them. I thought you would provide a way to sync
up on every step...

Also, I thought you had a variable in your kexec series that would prevent all further
logging and measuring once the log had been marshalled during kexec 'exec' stage
and this wasn't necessary.

   Stefan



This patch series would be a prerequisite for the next version of kexec
load/execute series[1] and the future IMA log snapshotting patch series.

[1] https://lore.kernel.org/all/20230703215709.1195644-1-tusharsu@xxxxxxxxxxxxxxxxxxx/
     ima: measure events between kexec load and execute

[2] https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part3_Commands_pub.pdf
     Section 22.4.2, Page 206.

Tushar Sugandhi (6):
   tpm: implement TPM2 function to get update counter
   tpm: provide functionality to get update counter
   ima: get TPM update counter
   ima: implement functionality to measure TPM update counter
   ima: measure TPM update counter at ima_init
   kexec: measure TPM update counter in ima log at kexec load

  drivers/char/tpm/tpm-interface.c   | 28 +++++++++++++++++
  drivers/char/tpm/tpm.h             |  3 ++
  drivers/char/tpm/tpm2-cmd.c        | 48 ++++++++++++++++++++++++++++++
  include/linux/ima.h                |  1 +
  include/linux/tpm.h                |  8 +++++
  kernel/kexec_file.c                |  3 ++
  security/integrity/ima/ima.h       |  2 ++
  security/integrity/ima/ima_init.c  |  3 ++
  security/integrity/ima/ima_main.c  | 29 ++++++++++++++++++
  security/integrity/ima/ima_queue.c | 16 ++++++++++
  10 files changed, 141 insertions(+)


_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux