llext: load: memcpy section header

[JordanYates]

When loading from .elf files, it is not guaranteed that section headers are word aligned within the .elf file. Attempting to perform a direct assignment results in the compiler assuming the input pointer is aligned, resulting in usage faults if the assumption is broken.

Example logs from my first attempt loading an .elf

START - test_loading
qemu-system-arm: warning: icount sleep disabled and no active timers
D: Loading ELF data...
D: Loading relocatable ELF
D: Finding ELF tables...
D: section 0 at 0: name 0, type 0, flags 0, addr 0, align 0, size 0, link 0, info 0
D: section 1 at 0x34: name 31, type 1, flags 0x6, addr 0, align 0x4, size 56, link 0, info 0
D: section 2 at 0x274: name 27, type 9, flags 0x40, addr 0, align 0x4, size 16, link 10, info 1
D: section 3 at 0x6c: name 37, type 1, flags 0x3, addr 0, align 0x1, size 0, link 0, info 0
D: section 4 at 0x6c: name 43, type 8, flags 0x3, addr 0, align 0x1, size 0, link 0, info 0
D: section 5 at 0x6c: name 48, type 1, flags 0x2, addr 0, align 0x4, size 57, link 0, info 0
D: section 6 at 0xa8: name 60, type 1, flags 0x2, addr 0, align 0x4, size 16, link 0, info 0
D: section 7 at 0x284: name 56, type 9, flags 0x40, addr 0, align 0x4, size 32, link 10, info 6
D: section 8 at 0xb8: name 74, type 1, flags 0x30, addr 0, align 0x1, size 33, link 0, info 0
D: section 9 at 0xd9: name 83, type 1879048195, flags 0, addr 0, align 0x1, size 47, link 0, info 0
D: section 10 at 0x108: name 1, type 2, flags 0, addr 0, align 0x4, size 288, link 11, info 15
D: symtab at 10
E: ***** USAGE FAULT *****
E:   Unaligned memory access
E: r0/a1:  0x00000010  r1/a2:  0x0000f174  r2/a3:  0x00000000
E: r3/a4:  0x00005179 r12/ip:  0x200025c0 r14/lr:  0x200005ee
E:  xpsr:  0x61000000
E: Faulting instruction address (r15/pc): 0x00004352
E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
E: Current thread: 0x200008c0 (test_loading)
E: Halting system

[pillo79]

Thanks!

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[lyakh]

wow, interesting. Is this compiler-specific? IIRC I've seen a structure assignment being replaced by the compiler with a memcpy builtin. That implementation shouldn't assume any alignment. And in general - as long as there's no alignment attribute, is it valid to assume any such alignment? I think structures are defined to be aligned in arrays, but stand-alone - I wasn't aware of such restrictions at least

[teburd]

We've ran into similar issues with mipi sys-t logging in the past which, yes, when derefencing arbitrary pointers and applying assignment would result in unaligned access faults just like this.

[lyakh]

@teburd but that depends on the type of the pointer. If it's a char * certainly no alignment is needed. For a 2-byte type a two-byte alignment is needed and so on. And for a structure? Even the fact that the linker placed a section header above without a 4-byte alignment suggests, that it's valid. And then the compiler fails to generate code to read it. Interesting.

[JordanYates]

Even the fact that the linker placed a section header above without a 4-byte alignment suggests, that it's valid

Its not clear to me why the section header should have any alignment requirements, its a binary data structure, not executable code. Even if it did have an alignment, what should that be? A uint32_t alignment, that would work fine for the 32 bit targets, would still have an incorrect alignment on 64 bit platforms.