[Bug dynamic-link/23293] New: aarch64: getauxval is broken when run as ld.so ./exe and ld.so adjusts argv on the stack

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/23293] New: aarch64: getauxval is broken when run as ld.so ./exe and ld.so adjusts argv on the stack

glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23293

            Bug ID: 23293
           Summary: aarch64: getauxval is broken when run as ld.so ./exe
                    and ld.so adjusts argv on the stack
           Product: glibc
           Version: 2.27
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: nszabolcs at gmail dot com
  Target Milestone: ---

on several targets the rtld entry point (_dl_start_user) adjusts
argv on the stack to have it right for the executed application
and to avoid a misaligned sp in the application elf entry point.

getauxval seems to use a global GLRO(dl_auxv) value that is
computed before the adjustments.

affects at least aarch64 and arm.

$ cat a.c
#include <stdio.h>
#include <sys/auxv.h>

int main()
{
        for (int i=0; i < 40; i++)
                printf("%2d 0x%lx\n", i, getauxval(i));
}
$ ./a.out
 0 0x0
 1 0x0
 2 0x0
 3 0xaaaad59e5040
 4 0x38
 5 0x8
 6 0x1000
 7 0xffff9c5fd000
 8 0x0
 9 0xaaaad59e5670
10 0x0
11 0x3e8
12 0x3e8
13 0x3e8
14 0x3e8
15 0xffffce3884b8
16 0x807
17 0x64
18 0x0
19 0x0
20 0x0
21 0x0
22 0x0
23 0x0
24 0x0
25 0xffffce3884a8
26 0x0
27 0x0
28 0x0
29 0x0
30 0x0
31 0xffffce388ff0
32 0x0
33 0xffff9c628000
34 0x0
35 0x0
36 0x0
37 0x0
38 0x0
39 0x0
$ /lib/ld-linux-aarch64.so.1 ./a.out
 0 0x0
 1 0x0
 2 0x0
 3 0x0
 4 0x0
 5 0x0
 6 0x0
 7 0x0
 8 0x7
 9 0x0
10 0x0
11 0x0
12 0x0
13 0x0
14 0x0
15 0x0
16 0x807
17 0x0
18 0x0
19 0x0
20 0x0
21 0x0
22 0x0
23 0x0
24 0x0
25 0x0
26 0x0
27 0x0
28 0x0
29 0x0
30 0x0
31 0x0
32 0x0
33 0x0
34 0x0
35 0x0
36 0x0
37 0x0
38 0x0
39 0x0

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/23293] aarch64: getauxval is broken when run as ld.so ./exe and ld.so adjusts argv on the stack

glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23293

Szabolcs Nagy <nszabolcs at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |aarch64-*-*, arm-*-*

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/23293] aarch64: getauxval is broken when run as ld.so ./exe and ld.so adjusts argv on the stack

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23293

Szabolcs Nagy <nszabolcs at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|aarch64-*-*, arm-*-*        |aarch64-*-*, arm-*-*,
                   |                            |nios2, ia64, alpha,
                   |                            |s390-32, sparc

--- Comment #1 from Szabolcs Nagy <nszabolcs at gmail dot com> ---
i think it affects all targets with DL_ARGV_NOT_RELRO == 1

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/23293] aarch64: getauxval is broken when run as ld.so ./exe and ld.so adjusts argv on the stack

Sourceware - glibc-bugs mailing list
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23293

Michael Hudson-Doyle <michael.hudson at canonical dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michael.hudson at canonical dot co
                   |                            |m

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/23293] aarch64: getauxval is broken when run as ld.so ./exe and ld.so adjusts argv on the stack

Sourceware - glibc-bugs mailing list
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23293

--- Comment #2 from Michael Hudson-Doyle <michael.hudson at canonical dot com> ---
I've just run into this because it causes a glibc test failure when
libnss-systemd is enabled
(https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1869364).

Would a fix be for _dl_start_user to update _dl_auxv in the same way it updates
_dl_argv? Or is that just naive (start up code confuses me!)

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/23293] aarch64: getauxval is broken when run as ld.so ./exe and ld.so adjusts argv on the stack

Sourceware - glibc-bugs mailing list
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23293

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #3 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Michael Hudson-Doyle from comment #2)
> I've just run into this because it causes a glibc test failure when
> libnss-systemd is enabled
> (https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1869364).
>
> Would a fix be for _dl_start_user to update _dl_auxv in the same way it
> updates _dl_argv? Or is that just naive (start up code confuses me!)

I think this should work. There does not seems to be anything that stores the
address if auxv entries, only values read from the vector.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/23293] aarch64: getauxval is broken when run as ld.so ./exe and ld.so adjusts argv on the stack

Sourceware - glibc-bugs mailing list
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23293

Szabolcs Nagy <nsz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nsz at gcc dot gnu.org

--- Comment #4 from Szabolcs Nagy <nsz at gcc dot gnu.org> ---
(In reply to Florian Weimer from comment #3)

> (In reply to Michael Hudson-Doyle from comment #2)
> > I've just run into this because it causes a glibc test failure when
> > libnss-systemd is enabled
> > (https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1869364).
> >
> > Would a fix be for _dl_start_user to update _dl_auxv in the same way it
> > updates _dl_argv? Or is that just naive (start up code confuses me!)
>
> I think this should work. There does not seems to be anything that stores
> the address if auxv entries, only values read from the vector.

it may work, but i think _dl_start_user stack handling should
not be updated, it should be removed: the logic is backwards:

most targets have fragile asm for the rtld start code to shuffle
around entries on the stack, but such shuffling can be done in c
in the generic code (e.g. in dl_main).

this would also fix the (imo security) bug that the protection
of dl data is not consistent across targets (DL_ARGV_NOT_RELRO).

and all this mess is for saving a few cycles on targets where
you don't need to do the shuffling. i think the generic code
should work for all targets and those who wish to optimize
add some hacks (e.g. ifdef out the shuffling), not the other
way around.

i didnt get the chance to clean this up yet, so it's not fixed.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/23293] aarch64: getauxval is broken when run as ld.so ./exe and ld.so adjusts argv on the stack

Sourceware - glibc-bugs mailing list
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23293

--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Szabolcs Nagy from comment #4)

> (In reply to Florian Weimer from comment #3)
> > (In reply to Michael Hudson-Doyle from comment #2)
> > > I've just run into this because it causes a glibc test failure when
> > > libnss-systemd is enabled
> > > (https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1869364).
> > >
> > > Would a fix be for _dl_start_user to update _dl_auxv in the same way it
> > > updates _dl_argv? Or is that just naive (start up code confuses me!)
> >
> > I think this should work. There does not seems to be anything that stores
> > the address if auxv entries, only values read from the vector.
>
> it may work, but i think _dl_start_user stack handling should
> not be updated, it should be removed: the logic is backwards:
>
> most targets have fragile asm for the rtld start code to shuffle
> around entries on the stack, but such shuffling can be done in c
> in the generic code (e.g. in dl_main).
>
> this would also fix the (imo security) bug that the protection
> of dl data is not consistent across targets (DL_ARGV_NOT_RELRO).
>
> and all this mess is for saving a few cycles on targets where
> you don't need to do the shuffling. i think the generic code
> should work for all targets and those who wish to optimize
> add some hacks (e.g. ifdef out the shuffling), not the other
> way around.
>
> i didnt get the chance to clean this up yet, so it's not fixed.

That sounds of course very reasonable. As long as very manipulate the arguments
as arrays, the C code should be very portable. An assembler stub will still be
needed, but it will be much smaller.

I also think we should move the assembler code out of dl-machine.h while we are
at it. We can start out with an empty dl-start.S file, and gradually move ports
to follow the powerpc32 example.

--
You are receiving this mail because:
You are on the CC list for the bug.