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: <20231012153012.GA698406-robh@kernel.org>
Date: Thu, 12 Oct 2023 10:30:12 -0500
From: Rob Herring <robh@...nel.org>
To: Gatien CHEVALLIER <gatien.chevallier@...s.st.com>
Cc: Oleksii_Moisieiev@...m.com, gregkh@...uxfoundation.org, herbert@...dor.apana.org.au, davem@...emloft.net, krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org, alexandre.torgue@...s.st.com, vkoul@...nel.org, jic23@...nel.org, olivier.moysan@...s.st.com, arnaud.pouliquen@...s.st.com, mchehab@...nel.org, fabrice.gasnier@...s.st.com, andi.shyti@...nel.org, ulf.hansson@...aro.org, edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, hugues.fruchet@...s.st.com, lee@...nel.org, will@...nel.org, catalin.marinas@....com, arnd@...nel.org, richardcochran@...il.com, Frank Rowand <frowand.list@...il.com>, peng.fan@....nxp.com, linux-crypto@...r.kernel.org, devicetree@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, dmaengine@...r.kernel.org, linux-i2c@...r.kernel.org, linux-iio@...r.kernel.org, alsa-devel@...a-project.org, linux-media@...r.kernel.org, linux-mmc@...r.kernel.org, netdev@...r.kernel.org, linux-p
 .hy@...ts.infradead.org, linux-serial@...r.kernel.org, linux-spi@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH v6 10/11] ARM: dts: stm32: add ETZPC as a system bus for
 STM32MP15x boards

On Wed, Oct 11, 2023 at 10:49:58AM +0200, Gatien CHEVALLIER wrote:
> Hi Rob,
> 
> On 10/10/23 20:42, Rob Herring wrote:
> > On Tue, Oct 10, 2023 at 02:57:18PM +0200, Gatien Chevallier wrote:
> > > ETZPC is a firewall controller. Put all peripherals filtered by the
> > > ETZPC as ETZPC subnodes and reference ETZPC as an
> > > access-control-provider.
> > > 
> > > For more information on which peripheral is securable or supports MCU
> > > isolation, please read the STM32MP15 reference manual.
> > > 
> > > Signed-off-by: Gatien Chevallier <gatien.chevallier@...s.st.com>
> > > ---
> > > 
> > > Changes in V6:
> > >      	- Renamed access-controller to access-controllers
> > >      	- Removal of access-control-provider property
> > > 
> > > Changes in V5:
> > >      	- Renamed feature-domain* to access-control*
> > > 
> > >   arch/arm/boot/dts/st/stm32mp151.dtsi  | 2756 +++++++++++++------------
> > >   arch/arm/boot/dts/st/stm32mp153.dtsi  |   52 +-
> > >   arch/arm/boot/dts/st/stm32mp15xc.dtsi |   19 +-
> > >   3 files changed, 1450 insertions(+), 1377 deletions(-)
> > 
> > This is not reviewable. Change the indentation and any non-functional
> > change in one patch and then actual changes in another.
> 
> Ok, I'll make it easier to read.
> 
> > 
> > This is also an ABI break. Though I'm not sure it's avoidable. All the
> > devices below the ETZPC node won't probe on existing kernel. A
> > simple-bus fallback for ETZPC node should solve that.
> > 
> 
> I had one issue when trying with a simple-bus fallback that was the
> drivers were probing even though the access rights aren't correct.
> Hence the removal of the simple-bus compatible in the STM32MP25 patch.

But it worked before, right? So the difference is you have either added 
new devices which need setup or your firmware changed how devices are 
setup (or not setup). Certainly can't fix the latter case. You just need 
to be explicit about what you are doing to users.


> Even though a node is tagged with the OF_POPULATED flag when checking
> the access rights with the firewall controller, it seems that when
> simple-bus is probing, there's no check of this flag.

It shouldn't. Those flags are for creating the devices (or not) and 
removing only devices of_platform_populate() created.

> of_platform_populate() checks and sets the OF_POPULATED_BUS flag.
> Maybe that is my error and the firewall bus populate should set
> OF_POPULATED_BUS instead of OF_POPULATED. Is that correct?

Shrug. Off hand, I'd say probably not, but am not certain.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ