On 13:36 19.07.21, Sumit Garg wrote:

On Mon, 19 Jul 2021 at 12:40, Ahmad Fatoum [off-list ref] wrote:

quoted

Hello Andreas,

On 16.07.21 10:17, Andreas Rammhold wrote:

quoted

Before this commit the kernel could end up with no trusted key sources
even thought both of the currently supported backends (tpm & tee) were
compoiled as modules. This manifested in the trusted key type not being
registered at all.

I assume (TPM) trusted key module use worked before the TEE rework? If so,

an appropriate Fixes: Tag would then be in order.

quoted

When checking if a CONFIG_… preprocessor variable is defined we only
test for the builtin (=y) case and not the module (=m) case. By using
the IS_ENABLE(…) macro we to test for both cases.

It looks to me like you could now provoke a link error if TEE is a module
and built-in trusted key core tries to link against trusted_key_tee_ops.

That's true.

quoted

One solution for that IS_REACHABLE(). Another is to address the root cause,
which is the inflexible trusted keys Kconfig description:

- Trusted keys despite TEE support can still only be built when TCG_TPM is enabled
- There is no support to have TEE or TPM enabled without using those for
  enabled trusted keys as well
- As you noticed, module build of the backend has issues

I addressed these three issues in a patch[1], a month ago, but have yet to
receive feedback.

That's an oversight on my part since this patch was part of the new
CAAM trust source patch-set. Although I do admit that it was on my
TODO list. So I have provided some feedback on that patch. Can you
post the next version as an independent fix patch?

Thank you both for the feedback. In light of thes feedback and the
patchset that Ahmad posted I'll not address the issue and not send a v2
of this.

I'll try to squeeze in some time to test the other patch and provide
feedback.

Andi