| 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
| ||
|
Message-ID: <87o7kkxous.fsf@epam.com>
Date: Mon, 10 Jul 2023 06:27:56 +0000
From: Oleksii Moisieiev <Oleksii_Moisieiev@...m.com>
To: Rob Herring <robh@...nel.org>
CC: Peng Fan <peng.fan@....com>,
Gatien Chevallier <gatien.chevallier@...s.st.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
"davem@...emloft.net" <davem@...emloft.net>,
"krzysztof.kozlowski+dt@...aro.org"
<krzysztof.kozlowski+dt@...aro.org>,
"conor+dt@...nel.org" <conor+dt@...nel.org>,
"alexandre.torgue@...s.st.com" <alexandre.torgue@...s.st.com>,
"vkoul@...nel.org" <vkoul@...nel.org>,
"jic23@...nel.org" <jic23@...nel.org>,
"olivier.moysan@...s.st.com" <olivier.moysan@...s.st.com>,
"arnaud.pouliquen@...s.st.com" <arnaud.pouliquen@...s.st.com>,
"mchehab@...nel.org" <mchehab@...nel.org>,
"fabrice.gasnier@...s.st.com" <fabrice.gasnier@...s.st.com>,
"andi.shyti@...nel.org" <andi.shyti@...nel.org>,
"ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"hugues.fruchet@...s.st.com" <hugues.fruchet@...s.st.com>,
"lee@...nel.org" <lee@...nel.org>,
"will@...nel.org" <will@...nel.org>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"arnd@...nel.org" <arnd@...nel.org>,
"richardcochran@...il.com" <richardcochran@...il.com>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-stm32@...md-mailman.stormreply.com"
<linux-stm32@...md-mailman.stormreply.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-phy@...ts.infradead.org" <linux-phy@...ts.infradead.org>,
"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
Subject: Re: [PATCH 04/10] dt-bindings: treewide: add feature-domains
description in binding files
Hi Rob,
Rob Herring <robh@...nel.org> writes:
> On Fri, Jul 7, 2023 at 10:10 AM Oleksii Moisieiev
> <Oleksii_Moisieiev@...m.com> wrote:
>>
>>
>> Hi Rob,
>>
>> Rob Herring <robh@...nel.org> writes:
>>
>> > On Fri, Jul 07, 2023 at 02:07:18PM +0000, Oleksii Moisieiev wrote:
>> >>
>> >> Gatien Chevallier <gatien.chevallier@...s.st.com> writes:
>> >>
>> >> > feature-domains is an optional property that allows a peripheral to
>> >> > refer to one or more feature domain controller(s).
>> >> >
>> >> > Description of this property is added to all peripheral binding files of
>> >> > the peripheral under the STM32 firewall controllers. It allows an accurate
>> >> > representation of the hardware, where various peripherals are connected
>> >> > to this firewall bus. The firewall can then check the peripheral accesses
>> >> > before allowing it to probe.
>> >> >
>> >> > Signed-off-by: Gatien Chevallier <gatien.chevallier@...s.st.com>
>> >> > ---
>> >> >
>> >> > Disclaimer: Some error with dtbs_check will be observed as I've
>> >> > considered the property to be generic, as Rob asked
>> >> >
>> >> > Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml | 4 ++++
>> >> > Documentation/devicetree/bindings/dma/st,stm32-dma.yaml | 4 ++++
>> >> > Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml | 4 ++++
>> >> > Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml | 4 ++++
>> >> > Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml | 4 ++++
>> >> > .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 4 ++++
>> >> > Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml | 4 ++++
>> >> > .../devicetree/bindings/media/cec/st,stm32-cec.yaml | 4 ++++
>> >> > Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml | 4 ++++
>> >> > .../bindings/memory-controllers/st,stm32-fmc2-ebi.yaml | 4 ++++
>> >> > Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml | 4 ++++
>> >> > Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml | 5 +++++
>> >> > Documentation/devicetree/bindings/mmc/arm,pl18x.yaml | 4 ++++
>> >> > Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 4 ++++
>> >> > Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml | 4 ++++
>> >> > .../devicetree/bindings/regulator/st,stm32-vrefbuf.yaml | 4 ++++
>> >> > Documentation/devicetree/bindings/rng/st,stm32-rng.yaml | 4 ++++
>> >> > Documentation/devicetree/bindings/serial/st,stm32-uart.yaml | 4 ++++
>> >> > Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml | 4 ++++
>> >> > Documentation/devicetree/bindings/sound/st,stm32-sai.yaml | 4 ++++
>> >> > .../devicetree/bindings/sound/st,stm32-spdifrx.yaml | 4 ++++
>> >> > Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml | 4 ++++
>> >> > Documentation/devicetree/bindings/spi/st,stm32-spi.yaml | 4 ++++
>> >> > Documentation/devicetree/bindings/usb/dwc2.yaml | 4 ++++
>> >> > 24 files changed, 97 insertions(+)
>> >> >
>> >> > diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
>> >> > index b767ec72a999..daf8dcaef627 100644
>> >> > --- a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
>> >> > +++ b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
>> >> > @@ -50,6 +50,10 @@ properties:
>> >> > power-domains:
>> >> > maxItems: 1
>> >> >
>> >> > + feature-domains:
>> >> > + minItems: 1
>> >> > + maxItems: 3
>> >> > +
>> >>
>> >> I beliewe feature-domains is generic binding. This means that maxItems
>> >> can be implementation dependend. I would rather drop maxItems so the
>> >> following format will be possible:
>> >>
>> >> feature-domains = <&etzpc 1>, <&etzpc 2>, <&some_other_domain 1 2 3 4>
>> >> feature-domain-names = "firewall 1", "firewall 2", "other_domain"
>> >
>> > The above already allows this (not -names, but the number of entries).
>> >>
>> >> Also I beliewe driver will handle feature-domain-names property so it
>> >> will parse feature-domains only related to the firewall.
>> >
>> > Now I'm curious. What's an example that's not a firewall?
>> >
>> > (Note I'm still not happy with the naming of 'feature' as anything is a
>> > feature, but that's the least of the issues really.)
>> >
>>
>> The alternative usages of feature-domains was originally proposed by me
>> here:
>> https://urldefense.com/v3/__https://lore.kernel.org/lkml/c869d2751125181a55bc8a88c96e3a892b42f37a.1668070216.git.oleksii_moisieiev@epam.com/__;!!GF_29dbcQIUBPA!zHa-1LhJFYFC4vvB1OiKWJ8-NXvcBXNhsZuVi-Xnb4L6bNUC4yp8tSyIUMcKjyrEA5_UmIqNwUwCvMxNng$ [lore[.]kernel[.]org]
>>
>> Also I remember Peng Fan also was interested in those bindings.
>
> It helps to Cc people when you talk about them.
>
> If the parties interested in this want to see progress on this, you
> all must work together and show this is a solution for multiple
> platforms.
>
Sorry. Missed that.
>> I think the use-case when one node is protected by firewall and also is
>> controlled by scmi feature-domain-controller (As was proposed in my
>> patch series) may take place.
>
> But isn't the SCMI device protection interface the same thing? Some
> interface to say "can I access this device?" and/or control access to
> it.
My patch series introduce using of the feature-domain-controller to
control access for the devices across the VMs. In our case we have
virtualized system, controlled by Xen hypervisor with some amount of the
VMs called Domains. Each Domain is the complete OS and HW is
separated between them. We need SCMI to control power/clocks/resets etc
from each Domain. feature-domain-controller in our case is SCMI node and
each device will receive unique ID which match the ID from SCP firmware
to set the device permissions so the SCP will know whether to give
access to the resource for the Domain or not.
Those feature-domain-controller node and links from devices will be
processed by Xen during Domain creation and the DT for the Domain will
be generated without those bindings.
So probably Firewall will not see the scmi related links in the device
nodes, but I think that the case when the device node is linked to more
then one feature-domain-controller is possible because bindings are generic.
>
> The other possible use I'm aware of is system partitioning. OpenAMP or
> similar where an SoC is partitioned into multiple OS instances and
> peripherals are assigned to different partitions.
>
i.MX boards are also have system partitioning concept in SCFW.
>> As for the naming maybe you have some thoughts about better name?
>
> If I did, I would have. Something with 'access' in it is as far as I've gotten.
>
What do you think about access-controller or feature-access-controller?
Maybe it will fit better here if all potential use cases for this
bingins is to say if the device can be accessed.
--
Thanks,
Oleksii
Powered by blists - more mailing lists