linux-kernel - Re: [PATCH] binfmt_elf_fdpic: fix /proc/<pid>/auxv

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMo8BfKcjAvGB9yYr6osoeA38K6fnRx652m3b_2E-oYHA4_rbA@mail.gmail.com>
Date: Sun, 25 Aug 2024 20:28:15 -0700
From: Max Filippov <jcmvbkbc@...il.com>
To: Greg Ungerer <gregungerer@...tnet.com.au>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, 
	linux-fsdevel@...r.kernel.org, Eric Biederman <ebiederm@...ssion.com>, 
	Kees Cook <keescook@...omium.org>, Alexander Viro <viro@...iv.linux.org.uk>, 
	Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>
Subject: Re: [PATCH] binfmt_elf_fdpic: fix /proc/<pid>/auxv

Hi Greg,

On Tue, Aug 13, 2024 at 11:28 AM Max Filippov <jcmvbkbc@...il.com> wrote:
> On Mon, Aug 12, 2024 at 9:53 PM Greg Ungerer <gregungerer@...tnet.com.au> wrote:
> > On 13/8/24 04:02, Max Filippov wrote:
> > > On Sun, Aug 11, 2024 at 7:26 PM Greg Ungerer <gregungerer@...tnet.com.au> wrote:
> > >> On 23/3/24 05:54, Max Filippov wrote:
> > >>> Althought FDPIC linux kernel provides /proc/<pid>/auxv files they are
> > >>> empty because there's no code that initializes mm->saved_auxv in the
> > >>> FDPIC ELF loader.
> > >>>
> > >>> Synchronize FDPIC ELF aux vector setup with ELF. Replace entry-by-entry
> > >>> aux vector copying to userspace with initialization of mm->saved_auxv
> > >>> first and then copying it to userspace as a whole.
> > >>>
> > >>> Signed-off-by: Max Filippov <jcmvbkbc@...il.com>
> > >>
> > >> This is breaking ARM nommu builds supporting fdpic and elf binaries for me.
> > >>
> > >> Tests I have for m68k and riscv nommu setups running elf binaries
> > >> don't show any problems - I am only seeing this on ARM.

I see the following:
- the issue with the change is caused by unaccouncounted AUX vector
  entry AT_HWCAP2 that is defined for ARM, but not for any other
  architecture that you tested.
- in the original code this off-by-one error resulted in the last entry of the
  AUX vector being set to zero. Below are the stack dumps from the ARM
  kernels built by your script, one with my change (left) and the other where
  this change is reverted (right):

argc:
00000001  00000001

argv:
00b8ffde  00b8ffde
00000000  00000000

envp:
00b8ffe4  00b8ffe4
00b8ffeb  00b8ffeb
00000000  00000000

auxv entries:
00000010  00000010
000001d7  000001d7
0000001a  0000001a
00000000  00000000
00000006  00000006
00001000  00001000
00000011  00000011
00000064  00000064
00000003  00000003
00980034  00a00034
00000004  00000004
00000020  00000020
00000005  00000005
00000007  00000007
00000007  00000007
00a40000  00a40000
00000008  00000008
00000000  00000000
00000009  00000009
00984040  00a04040
0000000b  0000000b
00000000  00000000
0000000c  0000000c
00000000  00000000
0000000d  0000000d
00000000  00000000
0000000e  0000000e
00000000  00000000
00000017  00000017
00000000  00000000
0000001f  0000001f
00b8fff6  00b8fff6
0000000f  00000000
00b8ffcc  00000000
00000000  00000000
00000000  00000000

The fix is in correct accounting of space for the AT_HWCAP2 entry.

-- 
Thanks.
-- Max