linux-kernel - Re: [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode

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

Message-ID: <c57775fe-41ef-07f5-56a2-04b8f70797c1@denx.de>
Date:   Thu, 11 Mar 2021 12:43:04 +0100
From:   Marek Vasut <marex@...x.de>
To:     Alexandre TORGUE <alexandre.torgue@...com>,
        "Alex G." <mr.nuke.me@...il.com>,
        Gabriel FERNANDEZ - foss <gabriel.fernandez@...s.st.com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Etienne CARRIERE <etienne.carriere@...com>,
        Alexandre TORGUE - foss <alexandre.torgue@...s.st.com>
Cc:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-stm32@...md-mailman.stormreply.com" 
        <linux-stm32@...md-mailman.stormreply.com>
Subject: Re: [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode

On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
> Hi ALex

Hello everyone,

[...]

>> Subject: Re: [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode
>>
>> On 1/26/21 3:01 AM, gabriel.fernandez@...s.st.com wrote:
>>> From: Gabriel Fernandez <gabriel.fernandez@...s.st.com>
>>>
>>> Platform STM32MP1 can be used in configuration where some clocks and
>>> IP resets can relate as secure resources.
>>> These resources are moved from a RCC clock/reset handle to a SCMI
>>> clock/reset_domain handle.
>>>
>>> The RCC clock driver is now dependent of the SCMI driver, then we have
>>> to manage now the probe defering.
>>>
>>> v1 -> v2:
>>>     - fix yamllint warnings.
>>
>> Hi Gabriel,
>>
>> I don't have much clout with the maintainers, but I have to NAK this series
>> after finding major breakage.
>>
>> The problem with series is that it breaks pretty much every board it touches.
>> I have a DK2 here that I'm using for development, which no longer boots with
>> this series applied.
>>
>> The crux of the matter is that this series assumes all boards will boot with an
>> FSBL that implements a very specific SCMI clock tree. This is major ABI
>> breakage for anyone not using TF-A as the first stage bootloader. Anyone
>> using u-boot SPL is screwed.
>>
>> This series imposes a SOC-wide change via the dtsi files. So even boards that
>> you don't intend to convert to SCMI will get broken this way.
>> Adding a -no-scmi file that isn't used anywhere doesn't help things.
> 
> You are right. We mainly take care about NO ST (DH/...) boards, but  not really about current usage
> Of our stm32 boards. Several options exist:

Since a lot of people benefit from the good upstream support for the MP1 
_and_ keep updating their machines to get the latest fixes, it is very 
important to keep the current usage working.

> 1- Break the current ABI: as soon as those patches are merged, stm32mp157c-dk2.dtb will impose to use
> A tf-a for scmi clocks. For people using u-boot spl, the will have to create their own "no-secure" devicetree.

NAK, this breaks existing boards and existing setups, e.g. DK2 that does 
not use ATF.

> 2-As you suggest, create a new "secure" dtb per boards (Not my wish for maintenance perspectives).

I agree with Alex (G) that the "secure" option should be opt-in.
That way existing setups remain working and no extra requirements are 
imposed on MP1 users. Esp. since as far as I understand this, the 
"secure" part isn't really about security, but rather about moving clock 
configuration from Linux to some firmware blob.

> 3- Keep kernel device tree as they are and applied this secure layer (scmi clocks phandle) thanks to dtbo in
> U-boot.

Is this really better than
#include "stm32mp15xx-enable-secure-stuff.dtsi"
in a board DT ? Because that is how I imagine the opt-in "secure" option 
could work.

> The third could be the less costly.

[...]