linux-kernel - Re: Build error on -next due to tpm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <25269252-e45f-4692-a519-a0703b6800a1@arm.com>
Date: Wed, 12 Mar 2025 15:47:10 -0500
From: Stuart Yoder <stuart.yoder@....com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Thorsten Leemhuis <linux@...mhuis.info>, jarkko@...nel.org,
 linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org, lenb@...nel.org,
 rafael@...nel.org, jgg@...pe.ca, peterhuewe@....de,
 linux-integrity@...r.kernel.org,
 Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: Build error on -next due to tpm_crb.c changes?



On 3/11/25 4:17 PM, Sudeep Holla wrote:
> On Tue, Mar 11, 2025 at 01:25:50PM -0500, Stuart Yoder wrote:
>>
>>
>> On 3/11/25 11:51 AM, Thorsten Leemhuis wrote:
>>> On 11.03.25 16:53, Stuart Yoder wrote:
>>>> On 3/11/25 10:21 AM, Thorsten Leemhuis wrote:
>>>>> On 05.03.25 18:36, Stuart Yoder wrote:
>>>> [...]
>>>> So, it should not be possible on one had have
>>>> CONFIG_TCG_ARM_CRB_FFA being true when building tpm_crb.c
>>>> and false resulting in the tpm_crb_ffa.o not being
>>>> picked up in the build.
>>>
>>> Many thx for the answer. Maybe Fedora's way to prepare the .config files
>>> (which my package builds use to be close to Fedora's official packages)
>>> is doing something odd/wrong. Will take a closer look and report back.
>>
>> I've been experimenting with some different build config combinations
>> and have reproduced what must be the issue.
>>
>> This works fine:
>> <*>   TPM 2.0 CRB Interface                                         < >
>> TPM CRB over Arm FF-A Transport
>>
>> This works fine:
>> < >   TPM 2.0 CRB Interface                                         <*>
>> TPM CRB over Arm FF-A Transport
>>
>> This works fine:
>> <*>   TPM 2.0 CRB Interface                                         <*>
>> TPM CRB over Arm FF-A Transport
>>
>> This works fine:
>> <M>   TPM 2.0 CRB Interface                                         <M>
>> TPM CRB over Arm FF-A Transport
>>
>> This fails:
>> <*>   TPM 2.0 CRB Interface                                         <M>
>> TPM CRB over Arm FF-A Transport
>>
>> The 2 drivers are coupled, so we can't have one built as a module
>> and the other built-in.
>>
>> I'm not a Kconfig expert, and need to do some fiddling to see
>> if I can find a Kconfig syntax that prevents that failure scenario.
>>
> 
> 	default y if (TCG_CRB && ARM_FFA_TRANSPORT)
> 
> is the issue here. You can select it as built-in if either or one of the
> TCG_CRB and ARM_FFA_TRANSPORT is a module, but that is exactly what happens.
> Not sure if default value is a must for you. But just depends on each of
> these should be good enough and enable it in defconfig if needed. Or
> you can have multiple default at least 4 combinations I can see. Both
> are =y and either and both are =m

I would like a default, because if someone enables both
ARM_FFA_TRANSPORT and TPM_CRB I don't want them to forget to
turn on TCG_ARM_CRB_FFA.

I've experimented with a few ways of doing this and I think
this is simplest and gives the behavior we want:

config TCG_ARM_CRB_FFA
         tristate "TPM CRB over Arm FF-A Transport"
         depends on ARM_FFA_TRANSPORT && TCG_CRB
         default TCG_CRB

The TCG_ARM_CRB_FFA option only appears if both FFA and
TPM_CRB are enabled. And the default tracks the value
of TPM_CRB.

Thanks,
Stuart