Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
From:   "Eric W. Biederman" <ebiederm@xmission.com>
To:     Sebastian Ott <sebott@redhat.com>
Cc:     Thomas =?utf-8?Q?Wei=C3=9Fschuh?= <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
References: <20230914-bss-alloc-v1-1-78de67d2c6dd@weissschuh.net>
        <36e93c8e-4384-b269-be78-479ccc7817b1@redhat.com>
        <87zg1bm5xo.fsf@email.froward.int.ebiederm.org>
        <37d3392c-cf33-20a6-b5c9-8b3fb8142658@redhat.com>
Date:   Mon, 25 Sep 2023 04:50:33 -0500
In-Reply-To: <37d3392c-cf33-20a6-b5c9-8b3fb8142658@redhat.com> (Sebastian
        Ott's message of "Mon, 25 Sep 2023 11:20:51 +0200 (CEST)")
Message-ID: <87ttrimviu.fsf@email.froward.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [PATCH RFC] binfmt_elf: fully allocate bss pages
Precedence: bulk

Sebastian Ott <sebott@redhat.com> writes:

> 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:

Bah.  Too much cleanup at once.

I will respin.

> [   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 ]---

Eric