Re: [PATCH 1/2] powerpc-ieee1275: load grub at 8MB, not 2MB

[Vladimir 'phcoder' Serbinenko]

Was it tested on powerpc-based Macs? They're still useful for
debugging and developpement despite their age

On Tue, Nov 16, 2021 at 4:42 AM Daniel Axtens <dja@axtens.net> wrote:
>
> RHEL9.0 builds were failing to boot with bizzare errors about module
> licensing.
>
> This was first reported under PFW but reproduces under SLOF.
>
> What is going wrong?
> --------------------
>
> Much debugging later, it turned out that this was because their image was
> greater than 2MB - 16KB in size:
>
>  - The core.elf was 2126152 = 0x207148 bytes in size with the following
>    program headers (per readelf):
>
> Entry point 0x200000
> There are 4 program headers, starting at offset 52
>
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD           0x000160 0x00200000 0x00200000 0x21f98 0x2971c RWE 0x8
>   GNU_STACK      0x0220f8 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
>   LOAD           0x0220f8 0x00232000 0x00232000 0x1e4e50 0x1e4e50 RWE 0x4
>   NOTE           0x206f48 0x00000000 0x00000000 0x00200 0x00000 R   0x4
>
>  - SLOF places the ELF file at 0x4000 (after the reserved space for
>    interrupt handlers etc.) upwards. The image was 2126152 = 0x207148
>    bytes in size, so it runs from 0x4000 - 0x20b148. We'll call 0x4000 the
>    load address.
>
> 0x0        0x4000         0x20b148
>  |----------|--------------|
>  | reserved | ELF contents |
>
>  - SLOF then copies the first LOAD program header (for .text). That runs
>    for 0x21f98 bytes. It runs from
>       (load addr + 0x160) to (load addr + 0x160 + 0x21f98)
>     = 0x4160 to 0x260f8
>    and we copy it to 0x200000 to 0x221f98. This overwrites the end of the
>    image:
>
> 0x0       0x4000     0x200000        0x221f98
>  |----------|------------|---------------|
>  | reserved | ELF cont.. | .text section |
>
>  - SLOF zeros the bss up to PhysAddr + MemSize = 0x22971c
>
> 0x0       0x4000      0x200000       0x221f98 0x22971c
>  |----------|------------|---------------|--------|
>  | reserved | ELF cont.. | .text section | bss 0s |
>
>  - SLOF then goes to fulfil the next LOAD header (for mods), which is
>    for 0x1e4e50 bytes. We copy from
>       (load addr + 0x220f8) to (load addr + 0x220f8 + 0x1e4e50)
>     = 0x260f8 to 0x20af48
>    and we copy it to 0x232000 to 0x416e50:
>
> 0x0       0x4000      0x200000       0x221f98 0x22971c
>  |----------|------------|---------------|--------|
>  | reserved | ELF cont.. | .text section | bss 0s |
>                |-------------|
>                | copied area |
>             0x260f8      0x20af48
>
>    This goes poorly:
>
> 0x0       0x4000      0x200000       0x221f98 0x22971c 0x232000 0x40bf08      
> 0x416e50
>  
> |----------|------------|---------------|--------|-----|-----------|-------------|
>  | reserved | ELF cont.. | .text section | bss 0s | pad | some mods | .text 
> start |
>
> This matches the observations on the running system - 0x40bf08 was where
> the contents of memory no longer matched the contents of the ELF file.
>
> This was reported as a license verification failure on SLOF as the
> last module's .module_license section fell past where the corruption
> began.
>
> load-base
> ---------
>
> From LoPAR:
>
> B.10.1 Load Address
>
>   The client’s load address is specified by the value of the load-base
>   Configuration Variable. The value of load-base defines the default
>   load address for client programs when using the load
>   method. Load-base shall be a real address in real mode or a virtual
>   address in virtual mode. Note that this address represents the area,
>   within the first LMB, into which the client program file will be
>   read by load; it does not correspond to the addresses at which the
>   program will be executed. All of physical memory from load-base to
>   either the start of OF physical memory or the end of physical
>   memory, whichever comes first, shall be available for loading the
>   client program.
>
>     Note: The load-base address represents the area into which the
>           client program will be read by load and does not correspond
>           to the address at which the program will be executed.
>
> We can specify load-base via setting a configuration variable, via
> CAS, or via an 1275 PowerPC Note.
>
> We can indeed override load-base and successfully load such a binary
> in SLOF. Drop to the OF shell and run:
>
> 0 > a000000 to load-base-override
> 0 > boot
>
> Sadly, asking people to drop to OF is not a super practical
> solution. SLOF ignores the 1275 PowerPC Note, which is the only thing
> we can (sanely) set in grub rather than in OF.
>
> PFW's load-base also defaults to 0x4000 but will honour the note. (The
> PFW team has been asking me to get grub to include the note and set
> appropriate values. See the next patch.)
>
> Fixing this
> -----------
>
> Unless I'm mistaken, if we want backwards compat with SLOF, we will
> need to change grub so that we ask the linker instruct the loader to
> load the program data somewhere else, giving us more headroom for the
> ELF image.
>
> This is fairly straight-forward to do. I've picked 8MB as that's a
> fairly common size for the PReP partition. We could potentially pick
> 4MB, I think I've seen some partitions that size too.
>
> The tests with powerpc32 using the OpenBIOS OF implementation seem to
> still work. I have no 32-bit Apple hardware to test on.
>
> Signed-off-by: Daniel Axtens <dja@axtens.net>
> ---
>  grub-core/Makefile.core.def | 2 +-
>  include/grub/offsets.h      | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index 8022e1c0a794..ce338def0f84 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -89,7 +89,7 @@ kernel = {
>    i386_xen_pvh_ldflags     = '$(TARGET_IMG_BASE_LDOPT),0x100000';
>
>    mips_loongson_ldflags    = '-Wl,-Ttext,0x80200000';
> -  powerpc_ieee1275_ldflags = '-Wl,-Ttext,0x200000';
> +  powerpc_ieee1275_ldflags = '-Wl,-Ttext,0x800000';
>    sparc64_ieee1275_ldflags = '-Wl,-Ttext,0x4400';
>    mips_arc_ldflags    = '-Wl,-Ttext,$(TARGET_LINK_ADDR)';
>    mips_qemu_mips_ldflags    = '-Wl,-Ttext,0x80200000';
> diff --git a/include/grub/offsets.h b/include/grub/offsets.h
> index 871e1cd4c38c..8b2d6ab971be 100644
> --- a/include/grub/offsets.h
> +++ b/include/grub/offsets.h
> @@ -63,7 +63,7 @@
>  #define GRUB_KERNEL_SPARC64_IEEE1275_LINK_ADDR 0x4400
>
>  #define GRUB_KERNEL_POWERPC_IEEE1275_LINK_ALIGN 4
> -#define GRUB_KERNEL_POWERPC_IEEE1275_LINK_ADDR 0x200000
> +#define GRUB_KERNEL_POWERPC_IEEE1275_LINK_ADDR 0x800000
>
>  #define GRUB_KERNEL_MIPS_LOONGSON_LINK_ADDR         0x80200000
>
> --
> 2.32.0
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



-- 
Regards
Vladimir 'phcoder' Serbinenko