Enable cr50 tpm drivers

[10ne1]

HI,

This is the kernelci-core counterpart to the bootrr PR #12.

Here is an example run of the bootrr test with these configs and tpm2-tools on my dev setup.

[eballetbo]

See my comment in bootrr PR #12 about tpm2-tools. I think is not needed.

[10ne1]

@eballetbo I responded to bootrr PR #12. I think we need to keep tpm2-tools because not all drivers expose the same /sys/class/tpm info and by using tpm2-tols we use a standard open source userspace software stack to sanity check any driver on any devices (including non-Chromebooks) by validating communication with the /dev/tpm device directly.

[eballetbo]

LGTM

[gctucker]

The drivers expose /dev/tpm devices which will then be used by tpm2-tools in Debian images or a custom TPM userspace stack in ChromeOS images exercisable via the TAST test suite.

Are all the config options useful for tpm2-tools or are some only required for TAST?

Anything that is solely to enable TAST to run should be used only on the chromeos.kernelci.org instance to keep linux.kernelci.org as close to mainline defconfigs as possible.

[10ne1]

The drivers expose /dev/tpm devices which will then be used by tpm2-tools in Debian images or a custom TPM userspace stack in ChromeOS images exercisable via the TAST test suite.

Are all the config options useful for tpm2-tools or are some only required for TAST?

Anything that is solely to enable TAST to run should be used only on the chromeos.kernelci.org instance to keep linux.kernelci.org as close to mainline defconfigs as possible.

Yes, all these config options are required by tpm2-tools to enable various TPM chips on boards via i2s and i2c.

The choice of userspace stack (tpm2-tools or TAST / google tpm) is actually irrelevant, by enabling these configs any standards compliant userspace implementation should be able to talk to the TPM thips via these drivers. TAST + Google userspace is only available via ChromeOS, but the tpm2-tools is available everywhere including debian & buildroot.

[gctucker]

We'll need a respin of the buildroot image used on staging with the fix in bootrr to test this again. If it's all looking good we could have it merged tomorrow and deployed in production on Monday.

[gctucker]

Sorry for the delay on this. A new buildroot will be tested next week with all the pending changes.

[gctucker]

We had issues creating new buildroot images as it's now being done with kci_rootfs and the changes didn't work initially. Now this is all being resolved so hopefully all the PRs that depend on buildroot will also get resolved soon.

[nfraprado]

So, I was working on adding some kselftests and totally missed this PR, redoing the work of finding the missing configs. But since this PR is already here, I've rebased my work on top of it.

Since this PR was changed to only add the required kernel configs for adding support for TPM, it is standalone and doesn't require any other PR to get merged (ie it's not blocked). And the configs added in this PR would be useful even without merging the PRs related to the bootrr TPM test, since I've been working on #1025 and #1034 to add the tpm2 kselftest to some platforms and that test requires the configs added here. This also solves the question about the configs being useful upstream, since the tpm2 kselftest is part of the upstream kernel, so the changes in this PR are definitely useful for testing the upstream kernel.

Just to do a breakdown of the configs added here:

Needed for sona (#1034):

CONFIG_TCG_TIS_SPI=y
CONFIG_TCG_TIS_SPI_CR50=y
CONFIG_SPI=y
CONFIG_SPI_PXA2XX=y

Needed for grunt (#1025):

CONFIG_TCG_TIS_I2C_CR50=y

The following configs are needed for both, since they enable basic TPM operation. In theory we could get away without them because they're enabled by default in our current defconfig, but it's a good idea to explicitly enable them so that some future defconfig change doesn't break our TPM tests.

CONFIG_TCG_TPM=y
CONFIG_TCG_TIS=y

So I'd suggest we just merge this PR as is.

[gctucker]

The only thing, reading the discussion history, is that the TPM tests are being enabled in bootrr and that requires an updated buildroot image to confirm the config changes are working as expected. It just got side-tracked, now we have buildroot support in kci_rootfs so it's easier to create new images. It's something we should be able to all test and merge this week.

[nfraprado]

Right, so kernelci/bootrr#12 and kernelci/buildroot#13 which enable a TPM test in bootrr depend on this PR. What I'm saying is that this PR doesn't depend on those two. It just adds some configs, which should just make the TPM module usable in tests, but not change anything else. And for validation that the configs in this PR work, we could use #1025 which also depends on this PR.

But in any case, I'm not trying to rush anything and it's fine to me whichever way it goes, I'm just clarifying that this particular PR is not blocked on anything, and instead is a blocker for both bootrr's and kselftest's TPM tests.

[gctucker]

Yes but if we enable these configs and the TPM tests still don't produce the expected results then there's a problem somewhere. That's why I'd like to have the results before merging this PR, at the same time as the bootrr ones.

[gctucker]

Tested OK on staging with manual build with bootrr and buildroot required changes:
https://lava.collabora.co.uk/scheduler/job/5674285