linux-kernel - Re: [PATCH 0/4] Add support for the TPM FF-A start method

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z7iHaWPyq3KDG7J2@bogus>
Date: Fri, 21 Feb 2025 14:02:17 +0000
From: Sudeep Holla <sudeep.holla@....com>
To: Sumit Garg <sumit.garg@...nel.org>
Cc: Stuart Yoder <stuart.yoder@....com>, Sumit Garg <sumit.garg@...aro.org>,
	linux-integrity@...r.kernel.org, jarkko@...nel.org,
	peterhuewe@....de, jgg@...pe.ca, rafael@...nel.org, lenb@...nel.org,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jens Wiklander <jens.wiklander@...aro.org>,
	Sudeep Holla <sudeep.holla@....com>, Rob Herring <robh@...nel.org>
Subject: Re: [PATCH 0/4] Add support for the TPM FF-A start method

Hi Sumit,

On Fri, Feb 21, 2025 at 07:16:35PM +0530, Sumit Garg wrote:
> On Mon, Feb 17, 2025 at 10:56:58AM -0600, Stuart Yoder wrote:
> >
> > I don't see how changing TPM discovery to be via FF-A directly
> > would improve maintainability.
>
> You are considering ACPI at this point but when people want to use this
> TPM over FF-A on a platform using DT then it will require corresponding
> DT bindings. After that each platform has to enable TPM over FF-A in
> their corresponding ACPI/DT. All that won't be needed with auto
> discovery over FF-A.

I hear you and completely agree. However, someone thought it was a good idea
to align with other start methods and duplicate information in the TCG ACPI
specification. This is definitely a bad idea, as it may contradict the
firmware. All we needed was a simple flag to indicate whether FF-A is the
start method.

It sounds like a classic case of misalignment between specification authors
and practical implementation needs. Instead of a simple flag to indicate FF-A
as the start method, duplicating information in the TCG ACPI specification
seems unnecessary and potentially problematic—especially if it risks
conflicting with firmware behavior.

Anyway, I can't comment on how we ended up here, but this seems to be the reality.

--
Regards,
Sudeep