FreeBSD's armstub8-gic.bin or armstub8.bin is bigger than the reserve area is it loaded to; later part ends up overwritten

[Mark Millard]

On 2020-Feb-11, at 18:17, Mark Millard <marklmi at yahoo.com> wrote:

> Using FreeBSD's armstub8-gic.bin as the example that
> applies to my test context: It has something like 0x15bc
> bytes to the end of its last instruction. (I looked at
> the .elf from a build that I did.)
> 
> Doing an experiment to make the PSCI version request
> also report where it sees its _start,
> el3_exception_vectors, and loop addresses showed
> (my summary):
> 
> _start at 0x0
> el3_exception_vectors at 0x800
> loop at 0x100c
> (given my code additions that made the size 0x15c8
> instead of 0x15bc).
> 
> So: loaded to Address 0x0. I confirmed in ddb that
> I see the code sequence starting at 0x0.
> 
> In my context boot -v was reporting the below.
> Compare and contrast the reserved size starting
> at 0x0 to the size of armstub8-gic's code
> span:
> 
>                   Type     Physical      Virtual   #Pages Attr
>               Reserved 000000000000            0 00000001 WB 
>     ConventionalMemory 000000001000         1000 00007ef1 WB 
> . . .
> Physical memory chunk(s):
>  0x00001000 - 0x39f48fff,   927 MB ( 237384 pages)
>  0x39f50000 - 0x39f50fff,     0 MB (      1 pages)
> . . .
> Excluded memory regions:
>  0x00000000 - 0x00000fff,     0 MB (      1 pages) NoAlloc 
>  0x32000000 - 0x33773fff,    23 MB (   6004 pages) NoAlloc 
> 
> Using ddb I confirmed that starting at 0x1000
> armstub8-gic.bin 's content had been replaced.
> That includes swap32, memmove, and fixup_dt_blob.
> 
> It looks to me like fixup_dt_blob needs to take
> into account the span of the armstub8* material
> and reserve at least 1 more page (past the page
> holding its self-observed start address) than is
> now reserved. (Wording avoids assuming that all
> aarch64 RPi*'s would use address 0x0.)
> 
> I do not claim to know that such a change would
> be sufficient. But the above seems to be a
> fragile structure.
> 
> 
> Detailed evidence techniques:
> 
> I adjusted a copy of sysutils/rpi-firmware 's armstub8
> code to have the pSCI version request also fill in
> the address of _start, el3_exception_vectors, and loop:
> 
> psci_version:
>        /* Return v0.2 */
>        adr     x3, loop
>        adr     x2, el3_exception_vectors
>        adr     x1, _start
>        mov     x0, #0x00000002
>        eret
> 
> I then added a direct use of arm_smccc_smc in a place
> early enough that I'd never seen the resulting version
> number to be wrong:
> 
>        uma_startup2();
> 
> //HACK!!!
> #ifdef __aarch64__
>        struct arm_smccc_res result;
>        int psci_version= arm_smccc_smc(0x84000000,0,0,0,0,0,0,0,&result);
>        printf("psci_version+: %x %lx %lx %lx %lx\n", psci_version, result.a0, result.a1, result.a2, result.a3);
> #endif
> }
> 
> I added the printf in order find what address range over
> which the armstub80-gic code would see itself span for my
> RPi4B based test context. The result was:
> 
> psci_version+: 2 2 0 800 100c
> 
> So:
> 
> (minor) version 2 (twice)
> _start at 0x0
> el3_exception_vectors at 0x800
> loop at 0x100c (given my code additions).
> 
> I'll note that this investigative hack was enough of
> a change that the RPi4B made it to a login prompt
> and I logged in. There were problems, but I could
> do some stuff. The failure mechanism for the
> "extra" cores (APs) was different, reporting
> very early on:
> 
> Starting CPU 1 (1)
> Failed to start CPU 1 (1)
> Starting CPU 2 (2)
> Failed to start CPU 2 (2)
> Starting CPU 3 (3)
> Failed to start CPU 3 (3)
> 

FYI for my test context:

Looks like dtb_ptr32 and kernel_entry32 end up
pointing to memory holding the (hexadecimal)
values (once updated from holding 0x0):


dtb_ptr32:       0x4000 (at 0xf8)
kernel_entry32: 0x80000 (at 0xfc)

I do not know how long the referenced memory
areas need to survive. They are not in an area
deliberately preserved (reserved) from what I
can tell. May be they do not need to be. But,
then, care would need to be taken to be sure
that the information needed was elsewhere
before an allocation and use could damage the
initial content.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)