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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1d33a7ee-3966-5c2e-5a6c-08a6e56d0f75@foss.st.com>
Date: Tue, 3 Oct 2023 09:57:24 +0200
From: Gatien CHEVALLIER <gatien.chevallier@...s.st.com>
To: Rob Herring <robh@...nel.org>
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 v5 03/11] dt-bindings: bus: document RIFSC



On 10/2/23 20:30, Rob Herring wrote:
> On Fri, Sep 29, 2023 at 04:28:44PM +0200, Gatien Chevallier wrote:
>> Document RIFSC (RIF security controller). RIFSC is a firewall controller
>> composed of different kinds of hardware resources.
>>
>> Signed-off-by: Gatien Chevallier <gatien.chevallier@...s.st.com>
>> ---
>>
>> Changes in V5:
>> 	- Renamed feature-domain* to access-control*
>>
>> Changes in V2:
>> 	- Corrected errors highlighted by Rob's robot
>> 	- No longer define the maxItems for the "feature-domains"
>> 	  property
>> 	- Fix example (node name, status)
>> 	- Declare "feature-domain-names" as an optional
>> 	  property for child nodes
>> 	- Fix description of "feature-domains" property
>>
>>   .../bindings/bus/st,stm32mp25-rifsc.yaml      | 105 ++++++++++++++++++
>>   1 file changed, 105 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml b/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml
>> new file mode 100644
>> index 000000000000..c28fceff3036
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml
>> @@ -0,0 +1,105 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/bus/st,stm32mp25-rifsc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: STM32 Resource isolation framework security controller
>> +
>> +maintainers:
>> +  - Gatien Chevallier <gatien.chevallier@...s.st.com>
>> +
>> +description: |
>> +  Resource isolation framework (RIF) is a comprehensive set of hardware blocks
>> +  designed to enforce and manage isolation of STM32 hardware resources like
>> +  memory and peripherals.
>> +
>> +  The RIFSC (RIF security controller) is composed of three sets of registers,
>> +  each managing a specific set of hardware resources:
>> +    - RISC registers associated with RISUP logic (resource isolation device unit
>> +      for peripherals), assign all non-RIF aware peripherals to zero, one or
>> +      any security domains (secure, privilege, compartment).
>> +    - RIMC registers: associated with RIMU logic (resource isolation master
>> +      unit), assign all non RIF-aware bus master to one security domain by
>> +      setting secure, privileged and compartment information on the system bus.
>> +      Alternatively, the RISUP logic controlling the device port access to a
>> +      peripheral can assign target bus attributes to this peripheral master port
>> +      (supported attribute: CID).
>> +    - RISC registers associated with RISAL logic (resource isolation device unit
>> +      for address space - Lite version), assign address space subregions to one
>> +      security domains (secure, privilege, compartment).
>> +
>> +properties:
>> +  compatible:
>> +    contains:
>> +      const: st,stm32mp25-rifsc
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  "#address-cells":
>> +    const: 1
>> +
>> +  "#size-cells":
>> +    const: 1
>> +
>> +  ranges: true
>> +
>> +  "#access-controller-cells":
>> +    const: 1
> 
> You should define what the cells contain here.
> 

Ok, I'll do this as well for the ETZPC binding

>> +
>> +  access-control-provider: true
>> +

Will be dropped, ditto for ETZPC.

>> +patternProperties:
>> +  "^.*@[0-9a-f]+$":
>> +    description: Peripherals
>> +    type: object
> 
>         additionalProperties: true
> 
>> +    properties:
>> +      access-controller:
>> +        minItems: 1
>> +        description:
>> +          The phandle of the firewall controller of the peripheral and the
>> +          platform-specific firewall ID of the peripheral.
>> +
>> +      access-controller-names:
>> +        minItems: 1
> 
> Drop all this. You have to define these in the specific device schemas
> anyways.
> 

I guess that:

patternProperties:
   "^.*@[0-9a-f]+$":
     description: Peripherals
     type: object

     required:
       - access-controller

is sufficient if I describe what the content of the cells will be in the
"#access-controller-cells" above. It avoids redundant information. I'll
make the change for V6, thank you.

Best regards,
Gatien

>> +
>> +    required:
>> +      - access-controller
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - "#address-cells"
>> +  - "#size-cells"
>> +  - access-control-provider
>> +  - "#access-controller-cells"
>> +  - ranges
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    // In this example, the usart2 device refers to rifsc as its domain
>> +    // controller.
>> +    // Access rights are verified before creating devices.
>> +
>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +
>> +    rifsc: bus@...80000 {
>> +        compatible = "st,stm32mp25-rifsc";
>> +        reg = <0x42080000 0x1000>;
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +        access-control-provider;
>> +        #access-controller-cells = <1>;
>> +        ranges;
>> +
>> +        usart2: serial@...e0000 {
>> +              compatible = "st,stm32h7-uart";
>> +              reg = <0x400e0000 0x400>;
>> +              interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
>> +              clocks = <&ck_flexgen_08>;
>> +              access-controller = <&rifsc 32>;
>> +        };
>> +    };
>> -- 
>> 2.25.1
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ