Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
Date:   Mon, 25 Sep 2023 11:20:51 +0200 (CEST)
From:   Sebastian Ott <sebott@redhat.com>
To:     "Eric W. Biederman" <ebiederm@xmission.com>
cc:     =?ISO-8859-15?Q?Thomas_Wei=DFschuh?= <linux@weissschuh.net>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Christian Brauner <brauner@kernel.org>,
        Kees Cook <keescook@chromium.org>,
        Mark Brown <broonie@kernel.org>, Willy Tarreau <w@1wt.eu>,
        linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH RFC] binfmt_elf: fully allocate bss pages
In-Reply-To: <87zg1bm5xo.fsf@email.froward.int.ebiederm.org>
Message-ID: <37d3392c-cf33-20a6-b5c9-8b3fb8142658@redhat.com>
References: <20230914-bss-alloc-v1-1-78de67d2c6dd@weissschuh.net> <36e93c8e-4384-b269-be78-479ccc7817b1@redhat.com> <87zg1bm5xo.fsf@email.froward.int.ebiederm.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Precedence: bulk

On Sun, 24 Sep 2023, Eric W. Biederman wrote:
> Sebastian Ott <sebott@redhat.com> 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@redhat.com/
>
> 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 ]---