linux-kernel - Re: [PATCH v6 0/5] Initial Support for Linksys EA9350 V3 (linksys-jamaica)

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <374339b4-3875-4680-a0b6-e0d3e69f4935@oss.qualcomm.com>
Date: Mon, 7 Oct 2024 23:52:10 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Linus Walleij <linus.walleij@...aro.org>,
        Karl Chan <exxxxkc@...googleoff.me>, Arnd Bergmann <arnd@...db.de>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, andersson@...nel.org,
        konradybcio@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
        conor+dt@...nel.org, mturquette@...libre.com, sboyd@...nel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-gpio@...r.kernel.org
Subject: Re: [PATCH v6 0/5] Initial Support for Linksys EA9350 V3
 (linksys-jamaica)

On 7.10.2024 10:23 PM, Linus Walleij wrote:
> On Mon, Oct 7, 2024 at 6:35 PM Karl Chan <exxxxkc@...googleoff.me> wrote:
> 
>> Also The original firmware from Linksys can only boot ARM32 kernels.
>>
>> As of now There seems to be no way to boot ARM64 kernels on those device.
> 
> So this is a Cortex-A53 Aarch64 system running in ARM32 mode.
> 
> So I got this interactive U-boot log from Karl showing how the attempt
> to boot an Aarch64 kernel manifests:
> 
> CBT U-Boot ver: 3.2.08  ([IPQ5018].[SPF11.3].[CSU2])
> 
> ## Loading kernel from FIT Image at 44000000 ...
>    Using 'standard' configuration
>    Trying 'kernel' kernel subimage
>      Description:  Kernel
>      Type:         Kernel Image
>      Compression:  uncompressed
>      Data Start:   0x440000a8
>      Data Size:    8249289 Bytes = 7.9 MiB
>      Architecture: AArch64
>      OS:           Linux
>      Load Address: 0x41208000
>      Entry Point:  0x41208000
>    Verifying Hash Integrity ... OK
> (...)
> ## Loading ramdisk from FIT Image at 44000000 ...
> (...)
> ## Loading fdt from FIT Image at 44000000 ...
> (...)
> fdt_fixup_qpic: QPIC: unable to find node '/soc/qpic-nand@...0000'
> Could not find PCI in device tree
> Using machid 0x8040001 from environment
> 
> Starting kernel ...
> 
> undefined instruction
> pc : [<41208004>]          lr : [<4a921f8f>]
> reloc pc : [<41208004>]    lr : [<4a921f8f>]
> sp : 4a822838  ip : 00000001     fp : 00000000
> r10: 4a83b914  r9 : 4a822ea0     r8 : 00000000
> r7 : 00000000  r6 : 41208000     r5 : 4a97d848  r4 : 00000000
> r3 : 644d5241  r2 : 4a0ae000     r1 : 08040001  r0 : 00000000
> Flags: nzCV  IRQs off  FIQs off  Mode SVC_32
> Resetting CPU ...
> 
> resetting ...
> 
> So perhaps someone knows how we can get around this.
> 
> It seems to me the U-Boot is in 32bit mode and tries to just
> execute an Aarch64 binary and that doesn't work.
> 
> What we need is a 32bit mode preamble that can switch
> the machine to Aarch64 and continue.
> 
> I don't know *how* to do that, but I would *guess* a botched
> return from exception where you provide your own stack
> with the Aarch64 state hardcoded on it should do the job?
> 
> The Aarch64 maintainers will know what to do.
> 
> Surely it should be possible to add a little code snippet
> to do this somewhere in memory, and that in turn jumps
> to execute the actual Aarch64 kernel in Aarch64 mode?

Not sure about this one, but older (10+yo) qcom socs had a
secure call to switch to 64bit..

Konrad