linux-kernel - Re: [PATCH v4 4/6] arm64: dts: renesas: rzg3s-smarc-som: Update dma-ranges for PCIe

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: <0a20c765-ff72-4c03-af84-dff3f4850fa4@tuxon.dev>
Date: Fri, 19 Sep 2025 10:38:52 +0300
From: Claudiu Beznea <claudiu.beznea@...on.dev>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: bhelgaas@...gle.com, lpieralisi@...nel.org, kwilczynski@...nel.org,
 mani@...nel.org, robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
 magnus.damm@...il.com, p.zabel@...gutronix.de, linux-pci@...r.kernel.org,
 linux-renesas-soc@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org,
 Claudiu Beznea <claudiu.beznea.uj@...renesas.com>,
 Wolfram Sang <wsa+renesas@...g-engineering.com>
Subject: Re: [PATCH v4 4/6] arm64: dts: renesas: rzg3s-smarc-som: Update
 dma-ranges for PCIe

Hi, Geert,

On 9/18/25 13:00, Geert Uytterhoeven wrote:
> Hi Claudiu,
> 
> On Thu, 18 Sept 2025 at 11:47, Claudiu Beznea <claudiu.beznea@...on.dev> wrote:
>> On 9/18/25 12:09, Geert Uytterhoeven wrote:
>>> On Fri, 12 Sept 2025 at 14:24, Claudiu <claudiu.beznea@...on.dev> wrote:
>>>> From: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
>>>>
>>>> The first 128MB of memory is reserved on this board for secure area.
>>>> Secure area is a RAM region used by firmware. The rzg3s-smarc-som.dtsi
>>>> memory node (memory@...00000) excludes the secure area.
>>>> Update the PCIe dma-ranges property to reflect this.
>>>>
>>>> Tested-by: Wolfram Sang <wsa+renesas@...g-engineering.com>
>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
>>>
>>> Thanks for your patch!
>>>
>>>> --- a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
>>>> +++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
>>>> @@ -214,6 +214,16 @@ &sdhi2 {
>>>>  };
>>>>  #endif
>>>>
>>>> +&pcie {
>>>> +       /* First 128MB is reserved for secure area. */
>>>
>>> Do you really have to take that into account here?  I believe that
>>> 128 MiB region will never be used anyway, as it is excluded from the
>>> memory map (see memory@...00000).
>>>
>>>> +       dma-ranges = <0x42000000 0 0x48000000 0 0x48000000 0x0 0x38000000>;
>>>
>>> Hence shouldn't you add
>>>
>>>     dma-ranges = <0x42000000 0 0x48000000 0 0x48000000 0x0 0x38000000>;
> 
> Oops, I really meant (forgot to edit after copying it):
> 
>     dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0x0 0x40000000>;
> 
>>>
>>> to the pcie node in arch/arm64/boot/dts/renesas/r9a08g045s33.dtsi
>>> instead, like is done for all other Renesas SoCs that have PCIe?
>>
>> I chose to add it here as the rzg3s-smarc-som.dtsi is the one that defines
>> the available memory for board, as the available memory is something board
>> dependent.
> 
> But IMHO it is independent from the amount of memory on the board.
> On other SoCs, it has a comment:
> 
>      /* Map all possible DDR as inbound ranges */
> 
>>
>> If you consider it is better to have it in the SoC file, please let me know.
> 
> Hence yes please.
> 
> However, I missed you already have:
> 
>     /* Map all possible DRAM ranges (4 GB). */
>     dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0x1 0x0>;
> 
> in r9a08g045.dtsi, so life's good.
> 
> +
>>>> +};
>>>> +
>>>> +&pcie_port0 {
>>>> +       clocks = <&versa3 5>;
>>>> +       clock-names = "ref";
>>>> +};
>>>
>>> This is not related.
>>
>> Ah, right! Could you please let me know if you prefer to have another patch
>> or to update the patch description?
> 
> Given the dma-ranges changes is IMHO not needed,

I kept it here as the driver configures the PCIe registers for the inbound
windows with the values passed though the dma-ranges. This is done through
rzg3s_pcie_set_inbound_windows() -> rzg3s_pcie_set_inbound_window(). The
controller will be aware that the secure area zone is something valid to
work with. In that case, if my understanding of PCIe windows is right, I
added this in the idea that an endpoint (a malicious one?) could DMA
into/from secure area if we don't exclude it here?

Thank you,
Claudiu

> this can just be
> a separate patch.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
>