| Message ID | 20200929165021.11731-1-pvorel@suse.cz (mailing list archive) |
|---|---|
| Headers | show |
| Series | TPM 2.0 fixes in IMA tests | expand |
On Tue, Sep 29, 2020 at 06:50:17PM +0200, Petr Vorel wrote: > Hi, > > few more fixes, mostly touching older kernels or evmctl versions. > Changes in 3rd and 4th commit. > > Kind regards, > Petr > > Petr Vorel (4): > IMA: Move get_algorithm_digest(), set_digest_index() to ima_setup.sh > IMA: Rewrite ima_boot_aggregate.c to new API > ima_tpm.sh: Fix calculating boot aggregate > ima_tpm.sh: Fix calculating PCR aggregate > > .../integrity/ima/src/ima_boot_aggregate.c | 113 ++++---- > .../integrity/ima/tests/ima_measurements.sh | 62 +--- > .../security/integrity/ima/tests/ima_setup.sh | 70 +++++ > .../security/integrity/ima/tests/ima_tpm.sh | 265 ++++++++++++++---- > 4 files changed, 341 insertions(+), 169 deletions(-) > > -- > 2.28.0 > Hi, is there something specific I should look at in this patch set? /Jarkko
Hi Jarkko, > Hi, is there something specific I should look at in this patch set? I'm sorry to bother you with LTP specific code. Can you have a quick look if I didn't overlook anything obvious in reading PCR files (read_pcr_tpm*())? I'm surprised that it's working on my TPM 2.0 which does not export /sys/kernel/security/tpm0/binary_bios_measurements (using evmctl). > /Jarkko Kind regards, Petr
On Wed, Sep 30, 2020 at 07:53:14AM +0200, Petr Vorel wrote: > Hi Jarkko, > > > Hi, is there something specific I should look at in this patch set? > > I'm sorry to bother you with LTP specific code. Can you have a quick look if I > didn't overlook anything obvious in reading PCR files (read_pcr_tpm*())? > > I'm surprised that it's working on my TPM 2.0 which does not export > /sys/kernel/security/tpm0/binary_bios_measurements (using evmctl). Thank you, this was actually really important remark and reminder. OK so I think James' patch is stuck because of me, i.e. https://lore.kernel.org/linux-integrity/20200911114820.GB6877@linux.intel.com/ I'm sorry about this. The final final conclusion is that the way it exports PCRs is just fine. Can you test this version? https://patchwork.kernel.org/patch/11759729/ I can then add reviewd-by and apply it and you don't have to do any sort of stupid hacks. /Jarkkko
Hi Jarkko, > On Wed, Sep 30, 2020 at 07:53:14AM +0200, Petr Vorel wrote: > > Hi Jarkko, > > > Hi, is there something specific I should look at in this patch set? > > I'm sorry to bother you with LTP specific code. Can you have a quick look if I > > didn't overlook anything obvious in reading PCR files (read_pcr_tpm*())? > > I'm surprised that it's working on my TPM 2.0 which does not export > > /sys/kernel/security/tpm0/binary_bios_measurements (using evmctl). > Thank you, this was actually really important remark and reminder. > OK so I think James' patch is stuck because of me, i.e. > https://lore.kernel.org/linux-integrity/20200911114820.GB6877@linux.intel.com/ > I'm sorry about this. The final final conclusion is that the way it > exports PCRs is just fine. That's a great, thank you for going to upstream James' patch. James, thanks for implementing it! > Can you test this version? Sure, I'll test it next week. > https://patchwork.kernel.org/patch/11759729/ > I can then add reviewd-by and apply it and you don't have to do any sort > of stupid hacks. I'll need to keep these hacks for older kernels, but it's great that there is a better solution. Other thing: do you know anybody practically uses more TPM devices in single machine? I'm asking that I work with tpm0 in ima_tpm.sh, but maybe I should allow user to redefine it to choose different device (or even run tests for all available devices). Kind regards, Petr > /Jarkkko
On Thu, Oct 01, 2020 at 02:01:25PM +0200, Petr Vorel wrote: > I'll need to keep these hacks for older kernels, but it's great that there is a > better solution. > > Other thing: do you know anybody practically uses more TPM devices in single > machine? I'm asking that I work with tpm0 in ima_tpm.sh, but maybe I should > allow user to redefine it to choose different device (or even run tests for all > available devices). You can create a proxy TPM device for a TPM emulator or a software TPM (e.g. could be an SGX enclave) by using ioctl interface /dev/vtpmx, provided by tpm_vtpm_proxy driver. QEMU provides a passthrough interface from TPM devices to the VM, which can be utilized for this. This one I know at least. > Kind regards, > Petr /Jarkko
Hi Jarkko,
can rely on /dev/tpm0 and /dev/tpmrm0 for TPM detection?
i.e.:
/dev/tpmrm0 => TPM 2.0
/dev/tpm0 => both TPM 1.2 or 2.0
none of them => No TPM device
I'm trying to get reliably TPM version (1, 2 or no TPM) for various kernel
versions (including very old ones like 3.x):
So far I have:
cat /sys/class/tpm/tpm0/tpm_version_major
[ -f /sys/class/tpm/tpm0/device/caps -o -f /sys/class/misc/tpm0/device/caps ] => TPM 1.2
[ ! -d /sys/class/tpm/tpm0/ -a ! -d /sys/class/misc/tpm0/ ] => no TPM
Then I grep
dmesg | grep -q 'activating TPM-bypass' => no TPM
dmesg | grep -q '1\.2 TPM (device-id' => TPM 1.2
dmesg | grep -q '2\.0 TPM (device-id' => TPM 2.0
But according to Mimi there are still some TPM 2.0 devices which does not export
sysfs files.
And I'd prefer avoid using dmesg (not on some embedded targets and not sure if
reliable for all TPM devices).
If I understand James's commit fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm<n>")
from v4.12-rc1 correctly /dev/tpmrm0 is really for TPM 2.0. But how to detect it
for v4.0 - v4.11 when /sys/class/tpm detection fails?
I haven't found anything obvious in drivers/char/tpm/tpm2-cmd.c from v4.0.
Thanks for info.
Kind regards,
Petr
On Tue, Oct 06, 2020 at 12:01:30PM +0200, Petr Vorel wrote: > Hi Jarkko, > > can rely on /dev/tpm0 and /dev/tpmrm0 for TPM detection? > i.e.: > /dev/tpmrm0 => TPM 2.0 > /dev/tpm0 => both TPM 1.2 or 2.0 > none of them => No TPM device I think that should work as tpmrm0 is unconditionally available for TPM devices. Since Linux v5.6 there has been a sysfs file called tpm_version_major available too. /Jarkko
On Tue, Oct 06, 2020 at 12:01:30PM +0200, Petr Vorel wrote: > If I understand James's commit fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm<n>") > from v4.12-rc1 correctly /dev/tpmrm0 is really for TPM 2.0. But how to detect it > for v4.0 - v4.11 when /sys/class/tpm detection fails? I'd send an idempotent TPM2 command to /dev/tpm0. I.e. if it works, it does not change the state. If it doesn't, you know that it is not TPM2 device. See the kernel function tpm2_probe() as an example of this approach. /Jarkko
On 10/6/2020 11:55 AM, Jarkko Sakkinen wrote: > On Tue, Oct 06, 2020 at 12:01:30PM +0200, Petr Vorel wrote: >> If I understand James's commit fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm<n>") >> from v4.12-rc1 correctly /dev/tpmrm0 is really for TPM 2.0. But how to detect it >> for v4.0 - v4.11 when /sys/class/tpm detection fails? > > I'd send an idempotent TPM2 command to /dev/tpm0. I.e. if it works, > it does not change the state. If it doesn't, you know that it is > not TPM2 device. > > See the kernel function tpm2_probe() as an example of this approach. > As good candidate is getcapability, because it is guaranteed never to require authorization.