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: <a3ce3fd1-6aca-49e4-b86b-75557526d62e@tuxon.dev>
Date: Fri, 19 Sep 2025 11:48:06 +0300
From: Claudiu Beznea <claudiu.beznea@...on.dev>
To: Manivannan Sadhasivam <mani@...nel.org>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>, bhelgaas@...gle.com,
 lpieralisi@...nel.org, kwilczynski@...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



On 9/19/25 11:25, Manivannan Sadhasivam wrote:
> On Fri, Sep 19, 2025 at 10:38:52AM +0300, Claudiu Beznea wrote:
>> 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?
>>
> 
> That's true. But do you really have an usecase to setup inbound window for the
> endpoints? What does the endpoint do with this memory?

I don't have a usecase for this. I did this update just to be safe for the
described scenario.

> 
> - Mani
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ