linux-kernel - Re: [PATCH] firmware: arm_scmi: Resolve dependency with TEE subsystem

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: <Y30LXW5Elcur5mlI@e120937-lin>
Date:   Tue, 22 Nov 2022 17:48:13 +0000
From:   Cristian Marussi <cristian.marussi@....com>
To:     Ludvig Pärsson <Ludvig.Parsson@...s.com>
Cc:     "etienne.carriere@...aro.org" <etienne.carriere@...aro.org>,
        "sudeep.holla@....com" <sudeep.holla@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "jens.wiklander@...aro.org" <jens.wiklander@...aro.org>,
        "sumit.garg@...aro.org" <sumit.garg@...aro.org>,
        "vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] firmware: arm_scmi: Resolve dependency with TEE subsystem

On Mon, Nov 14, 2022 at 01:47:25PM +0000, Ludvig Pärsson wrote:
> On Mon, 2022-11-14 at 12:29 +0100, Etienne Carriere wrote:
> > Hello all,
> > 

Hi Ludvig,

following up on the issues raised by this thread and a few proposals that
were flying around (online and offline), in the past days I took the chance
to have a go at a substantial rework of the init/probe sequences in the SCMI
core to address the issue you faced with SCMI TEE transport while trying to
untangle a bit the SCMI core startup sequences (... while also possibly not
breaking it all :P...)

In a nutshell, building on an idea from an offline chat with Etienne ad
Sudeep, now the SCMI bus initialization is split on its own and initialized at
subsys_initcall level, while the SCMI core stack, including the the SCMI TEE
transport layer, is moved at module_init layer together with the SCMI
driver users.

This *should* theoretically solve your issue ... (and it seems like all the
rest it's still working :P) ... so I was wondering if you can give a go
at the following pachset on your setup:

https://gitlab.arm.com/linux-arm/linux-cm/-/commits/scmi_rework_stack_init_draft/

... note that this is just a draft at the moment, which has undergone a
reasonable amount of testing on mailbox/virtio transports only in both a
SCMI builtin and/or modules scenario, but is no where ready for review.

The top three patches are really what you need BUT these are probably
tightly bound to that bunch of early fixes you can see in the
branch...so in other words better if you pick the whole branch for
testing :D

Once you've confirmed me that this solves your issues I'll start the
final cleanup for posting in the next cycle.

Thanks,
Cristian