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 16:00:02 +0200
From:   Stephan Gerhold <stephan@...hold.net>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>
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 Fri, Sep 15, 2023 at 03:52:36PM +0200, Konrad Dybcio wrote:
> 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?
> 

Hm no? As I wrote, with alloc-ranges = <0x0 0x86800000 0x0 0x8000000> it
also works on the close-to-QRD MSM8916 devices. There are some addresses
that don't work but those might also exist on APQ8016. I haven't tested
placing the firmware all over RAM on all sorts of obscure addresses (and
there is probably little advantage doing so).

With the limited alloc-ranges it would likely work on all devices that
are close to the reference design/firmware from Qualcomm.

Thanks,
Stephan