linux-kernel - Re: [PATCH 4/9] arm64: dts: qcom: msm8916: Reserve firmware memory dynamically

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]

Date:   Fri, 15 Sep 2023 15:52:36 +0200
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Stephan Gerhold <stephan@...hold.net>
Cc:     Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Andy Gross <agross@...nel.org>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/9] arm64: dts: qcom: msm8916: Reserve firmware memory
 dynamically

On 14.09.2023 16:09, Stephan Gerhold wrote:
> On Wed, Sep 13, 2023 at 09:39:50PM +0200, Konrad Dybcio wrote:
>> On 13.09.2023 12:14, Stephan Gerhold wrote:
>>> On Wed, Sep 13, 2023 at 10:12:12AM +0100, Bryan O'Donoghue wrote:
>>>> On 13/09/2023 10:06, Konrad Dybcio wrote:
>>>>> On 11.09.2023 19:41, Stephan Gerhold wrote:
>>>>>> Most of the reserved firmware memory on MSM8916 can be relocated when
>>>>>> respecting the required alignment. To avoid having to precompute the
>>>>>> reserved memory regions in every board DT, describe the actual
>>>>>> requirements (size, alignment, alloc-ranges) using the dynamic reserved
>>>>>> memory allocation.
>>>>>>
>>>>>> This approach has several advantages:
>>>>>>
>>>>>>   1. We can define "templates" for the reserved memory regions in
>>>>>>      msm8916.dtsi and keep only device-specific details in the board DT.
>>>>>>      This is useful for the "mpss" region size for example, which varies
>>>>>>      from device to device. It is no longer necessary to redefine all
>>>>>>      firmware regions to shift their addresses.
>>>>>>
>>>>>>   2. When some of the functionality (e.g. WCNSS, Modem, Venus) is not
>>>>>>      enabled or needed for a device, the reserved memory can stay
>>>>>>      disabled, freeing up the unused reservation for Linux.
>>>>>>
>>>>>>   3. Devices with special requirements for one of the firmware regions
>>>>>>      are handled automatically. For example, msm8916-longcheer-l8150
>>>>>>      has non-relocatable "wcnss" firmware that must be loaded exactly
>>>>>>      at address 0x8b600000. When this is defined as a static region,
>>>>>>      the other dynamic allocations automatically adjust to a different
>>>>>>      place with suitable alignment.
>>>>>>
>>>>>> All in all this approach significantly reduces the boilerplate necessary
>>>>>> to define the different firmware regions, and makes it easier to enable
>>>>>> functionality on the different devices.
>>>>>>
>>>>>> Signed-off-by: Stephan Gerhold <stephan@...hold.net>
>>>>>> ---
>>>>> [...]
>>>>>
>>>>>>   		mpss_mem: mpss@...00000 {
>>>>>> +			/*
>>>>>> +			 * The memory region for the mpss firmware is generally
>>>>>> +			 * relocatable and could be allocated dynamically.
>>>>>> +			 * However, many firmware versions tend to fail when
>>>>>> +			 * loaded to some special addresses, so it is hard to
>>>>>> +			 * define reliable alloc-ranges.
>>>>>> +			 *
>>>>>> +			 * alignment = <0x0 0x400000>;
>>>>>> +			 * alloc-ranges = <0x0 0x86800000 0x0 0x8000000>;
>>>>>> +			 */
>>>>> Do we know of any devices that this would actually work on?
>> [...]
>>>  - On DB410c it works just fine. All addresses I tried work without any
>>>    problems.
>>>
>>>  - On longcheer-l8150 the modem firmare works fine when the memory
>>>    region starts somewhere between 0x86800000 and 0x8a800000. It also
>>>    works again after 0x8e800000. But on anything between 0x8a800000 and
>>>    0x8e800000 it's broken for who knows what reason.
>>> [...]
>> Were you able to find a phone (likely a very reference-design-based
>> one) that this worked on, btw?
> 
> Actually I would count the Longcheer devices (l8150 = Wileyfox Swift and
> l8910 = BQ Aquaris X5) to the category of close-to-QRD-based devices.
> Based on quick tests both behave like described above (only
> 0x8a800000-0x8e800000 is broken). Same for wingtech-wt88047.
> 
> In other words, for those using the dynamic allocation would work fine,
> because the alloc-ranges = <0x0 0x86800000 0x0 0x8000000>; only includes
> working start addresses from 0x86800000 to ~0x89800000 (with a size of
> 0x5000000).
> 
> I guess I could use it for them and only make other devices use a fixed
> address. But I also don't quite have the capacity to test every device
> to see if relocating the region works or not.
> 
> I think it's still easiest to allocate mpss on a fixed address
> everywhere. The only real disadvantage is that overriding "reg", e.g.
> 
> 	&mpss_mem {
> 		reg = <0x0 0x86800000 0x0 0x5100000>;
> 	};
> 
> is a bit more ugly than overriding size:
> 
> 	&mpss_mem {
> 		size = <0x0 0x5100000>;
> 	};
> 
> but well, this is a very minor disadvantage.
So in other words, this only *really* works on apq8016?

Konrad