linux-kernel - Re: [PATCH] Revert "arm64: zynqmp: Add an OP-TEE node to the device tree"

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: <199062ba-9a0d-40ae-ac8c-0fbed5615cf8@vaisala.com>
Date: Tue, 25 Nov 2025 13:42:39 +0200
From: Tomas Melin <tomas.melin@...sala.com>
To: Michal Simek <michal.simek@....com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>
Cc: devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Revert "arm64: zynqmp: Add an OP-TEE node to the device
 tree"

Hi,

On 25/11/2025 12:30, Michal Simek wrote:
> 
> 
> On 11/25/25 08:53, Tomas Melin wrote:
>> This reverts commit 06d22ed6b6635b17551f386b50bb5aaff9b75fbe.
>>
>> OP-TEE logic in U-Boot automatically injects a reserved-memory
>> node along with optee firmware node to kernel device tree.
>> The injection logic is dependent on that there is no manually
>> defined optee node. Having the node in zynqmp.dtsi effectively
>> breaks OP-TEE's insertion of the reserved-memory node, causing
>> memory access violations during runtime.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@...sala.com>
>> ---
>> For further information about the U-Boot logic related
>> to this, see lib/optee/optee.c in U-Boot repository.
> 
> What's the behavior with EDK2?
Sorry, I cannot comment on that.

> 
> U-Boot also have optee driver. How is it probed when you remove this node?
This is about the injection of the nodes to the kernel device tree. So
in the U-Boot side, optee driver can be enabled or not. This passing of
the optee nodes will happen outside of optee driver context (image-fdt).
The OP-TEE logic will not insert the required reserved memory regions
into the kernel side devicetree in case the node is already present and
that is a real problem.
If this change eventually is mapped from kernel to U-Boot side, OP-TEE
needs to be enabled by boards that use OP-TEE from U-Boot. But that
sounds logical and how it was before, why would OP-TEE be automatically
enabled.

Thanks,
Tomas


> 
> Thanks,
> Michal
> 
>