On 4/12/22 19:03, Niklas Cassel wrote:
> bFLT binaries are usually created using elf2flt.
>
> The linker script used by elf2flt has defined the .data section like the
> following for the last 19 years:
>
> .data : {
> _sdata = . ;
> __data_start = . ;
> data_start = . ;
> *(.got.plt)
> *(.got)
> FILL(0) ;
> . = ALIGN(0x20) ;
> LONG(-1)
> . = ALIGN(0x20) ;
> ...
> }
>
> It places the .got.plt input section before the .got input section.
> The same is true for the default linker script (ld --verbose) on most
> architectures except x86/x86-64.
>
> The binfmt_flat loader should relocate all GOT entries until it encounters
> a -1 (the LONG(-1) in the linker script).
>
> The problem is that the .got.plt input section starts with a GOTPLT header
> that has the first word (two u32 entries for 64-bit archs) set to -1.
> See e.g. the binutils implementation for architectures [1] [2] [3] [4].
>
> This causes the binfmt_flat loader to stop relocating GOT entries
> prematurely and thus causes the application to crash when running.
>
> Fix this by ignoring -1 in the first two u32 entries in the .data section.
>
> A -1 will only be ignored for the first two entries for bFLT binaries with
> FLAT_FLAG_GOTPIC set, which is unconditionally set by elf2flt if the
> supplied ELF binary had the symbol _GLOBAL_OFFSET_TABLE_ defined, therefore
> ELF binaries without a .got input section should remain unaffected.
>
> Tested on RISC-V Canaan Kendryte K210 and RISC-V QEMU nommu_virt_defconfig.
>
> [1] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elfnn-riscv.c;hb=binutils-2_38#l3275
> [2] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elfxx-tilegx.c;hb=binutils-2_38#l4023
> [3] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elf32-tilepro.c;hb=binutils-2_38#l3633
> [4] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elfnn-loongarch.c;hb=binutils-2_38#l2978
>
> Cc: <stable@xxxxxxxxxxxxxxx>
> Signed-off-by: Niklas Cassel <niklas.cassel@xxxxxxx>
> ---
> RISC-V elf2flt patches are still not merged, they can be found here:
> https://github.com/floatious/elf2flt/tree/riscv
>
> buildroot branch for k210 nommu (including this patch and elf2flt patches):
> https://github.com/floatious/buildroot/tree/k210-v14
>
> fs/binfmt_flat.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
> index 626898150011..b80009e6392e 100644
> --- a/fs/binfmt_flat.c
> +++ b/fs/binfmt_flat.c
> @@ -793,8 +793,17 @@ static int load_flat_file(struct linux_binprm *bprm,
> u32 addr, rp_val;
> if (get_user(rp_val, rp))
> return -EFAULT;
> - if (rp_val == 0xffffffff)
> + /*
> + * The first word in the GOTPLT header is -1 on certain
> + * architechtures. (On 64-bit, that is two u32 entries.)
> + * Ignore these entries, so that we stop relocating GOT
> + * entries first when we encounter the -1 after the GOT.
> + */
/*
* The first word in the GOTPLT header is -1 on certain
* architectures (on 64-bit, that is two u32 entries).
* Ignore these entries so that we stop relocating GOT
* entries when we encounter the first -1 entry after
* the GOTPLT header.
*/
> + if (rp_val == 0xffffffff) {
> + if (rp - (u32 __user *)datapos < 2)
> + continue;
Would it be safer to check that the following rp_val is also -1 ? Also,
does this work with 32-bits arch ? Shouldn't the "< 2" be "< 1" for
32-bits arch ?
> break;
> + }
> if (rp_val) {
> addr = calc_reloc(rp_val, libinfo, id, 0);
> if (addr == RELOC_FAILED) {
--
Damien Le Moal
Western Digital Research
