On Sun, 24 Sep 2023, Eric W. Biederman wrote:
Sebastian Ott <sebott@xxxxxxxxxx> writes:Hej, since we figured that the proposed patch is not going to work I've spent a couple more hours looking at this (some static binaries on arm64 segfault during load [0]). The segfault happens because of a failed clear_user() call in load_elf_binary(). The address we try to write zeros to is mapped with correct permissions. After some experiments I've noticed that writing to anonymous mappings work fine and all the error cases happend on file backed VMAs. Debugging showed that in elf_map() we call vm_mmap() with a file offset of 15 pages - for a binary that's less than 1KiB in size. Looking at the ELF headers again that 15 pages offset originates from the offset of the 2nd segment - so, I guess the loader did as instructed and that binary is just too nasty? Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x0000000000000178 0x0000000000000178 R E 0x10000 LOAD 0x000000000000ffe8 0x000000000041ffe8 0x000000000041ffe8 0x0000000000000000 0x0000000000000008 RW 0x10000 NOTE 0x0000000000000120 0x0000000000400120 0x0000000000400120 0x0000000000000024 0x0000000000000024 R 0x4 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0x10 As an additional test I've added a bunch of zeros at the end of that binary so that the offset is within that file and it did load just fine. On the other hand there is this section header: [ 4] .bss NOBITS 000000000041ffe8 0000ffe8 0000000000000008 0000000000000000 WA 0 0 1 "sh_offset This member's value gives the byte offset from the beginning of the file to the first byte in the section. One section type, SHT_NOBITS described below, occupies no space in the file, and its sh_offset member locates the conceptual placement in the file. " So, still not sure what to do here.. Sebastian [0] https://lore.kernel.org/lkml/5d49767a-fbdc-fbe7-5fb2-d99ece3168cb@xxxxxxxxxx/I think that .bss section that is being generated is atrocious. At the same time I looked at what the linux elf loader is trying to do, and the elf loader's handling of program segments with memsz > filesz has serious remnants a.out of programs allocating memory with the brk syscall. Lots of the structure looks like it started with the assumption that there would only be a single program header with memsz > filesz the way and that was the .bss. The way things were in the a.out days and handling of other cases has been debugged in later. So I have modified elf_map to always return successfully when there is a zero filesz in the program header for an elf segment. Then I have factored out a function clear_tail that ensures the zero padding for an entire elf segment is present. Please test this and see if it causes your test case to work.
Sadly, that causes issues for other programs: [ 44.164596] Run /init as init process [ 44.168763] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 44.176409] CPU: 32 PID: 1 Comm: init Not tainted 6.6.0-rc2+ #89 [ 44.182404] Hardware name: GIGABYTE R181-T92-00/MT91-FS4-00, BIOS F34 08/13/2020 [ 44.189786] Call trace: [ 44.192220] dump_backtrace+0xa4/0x130 [ 44.195961] show_stack+0x20/0x38 [ 44.199264] dump_stack_lvl+0x48/0x60 [ 44.202917] dump_stack+0x18/0x28 [ 44.206219] panic+0x2e0/0x350 [ 44.209264] do_exit+0x370/0x390 [ 44.212481] do_group_exit+0x3c/0xa0 [ 44.216044] get_signal+0x800/0x808 [ 44.219521] do_signal+0xfc/0x200 [ 44.222824] do_notify_resume+0xc8/0x418 [ 44.226734] el0_da+0x114/0x120 [ 44.229866] el0t_64_sync_handler+0xb8/0x130 [ 44.234124] el0t_64_sync+0x194/0x198 [ 44.237776] SMP: stopping secondary CPUs [ 44.241740] Kernel Offset: disabled [ 44.245215] CPU features: 0x03000000,14028142,10004203 [ 44.250342] Memory Limit: none [ 44.253383] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
