4 ms·

On Linux, after argc, argv and envp comes the even more mysterious auxv, a key-value store for binary data. The kernel shoves a lot of interesting stuff into au

On Linux, after argc, argv and envp comes the even more mysterious auxv, a key-value store for binary data. The kernel shoves a lot of interesting stuff into auxv, including AT_RANDOM - 16 random bytes (used to construct stack canaries and function pointer encryption keys), AT_HWCAP (processor capability flags), and AT_SECURE (a flag specifying if the program is setuid and therefore security sensitive). Although a lot of it is meant just for internal C library use, it can be helpful for programmers too (e.g. being able to check hardware capabilities without a trip to cpuid).

cryptonector 6y ago
This is true for ELF, not just Linux. And it need not be true for a.out (IIRC it's not true for a.out executables on Linux or any other Unix or Unix-like OS that supports a.out executable formats). There are a few auxiliary vector keys that are standard per-ELF, and others that are platform-specific. The original purpose of the auxv was to provide the ELF interpreter (ld.so) with information it needs in order to bootstrap.
- skissane 6y ago
  > IIRC it's not true for a.out executables on Linux I was surprised to discover a.out support is still there in the kernel [1]. There has been talk on LKML about whether to remove it [2] – apparently it has accumulated regression bugs (particularly in the area of core dumping) which nobody has noticed and fixed, which is the inevitable fate of code that hangs around for decades after everybody stops using it – but it still hasn't been removed yet. [1] https://github.com/torvalds/linux/blob/master/fs/binfmt_aout.c https://github.com/torvalds/linux/blob/master/fs/binfmt_aout... [2] https://www.lkml.org/lkml/2019/3/5/389 https://www.lkml.org/lkml/2019/3/5/389
TallGuyShort 6y ago
Huh - I remember using `char env` as the third parameter to main. After a quick Googling, it would seem that's a GCC-specific thing. Surprised there's a Linux-specific (or ELF-specific, as another commented) convention other than that one.
- jlokier 6y ago
  It isn't specific to GCC at all. It's widespread among unixes historically (and they generally have their own C compiler which is not GCC), and it was mentioned in the C89 standard. However, it is not part of standard C or POSIX/SUS. https://stackoverflow.com/a/10321474 https://stackoverflow.com/a/10321474
- jwilk 6y ago
  HN's comment monster ate your asterisks. :-( It should be: char **env
  - TallGuyShort 6y ago
    Ah ha - now there's an argument in favor of the `char *env[]` notation!
rvnx 6y ago
Your post is the reason I like HN :) Thanks for sharing
saagarjha 6y ago
GDB also uses it to figure out where the binary is slid in memory (it reads /proc/pid/auxv, though, not the stack). AT_HWCAP is particularly useful on ARM because as far as I understand the feature registers are normally not readable by userspace and this is probably the easiest way to grab it on Linux.
1vuio0pswjnm7 6y ago
It is nice to see some BSD asm for a change (I know, someone will probably say this is about C, not asm). If one is hoping to learn anything about assembly language from reading the internet, most material found will focus on Linux or Windows. Even the HN comments on a blog post about BSD asm are about Linux.

cryptonector 6y ago

This is true for ELF, not just Linux. And it need not be true for a.out (IIRC it's not true for a.out executables on Linux or any other Unix or Unix-like OS that supports a.out executable formats). There are a few auxiliary vector keys that are standard per-ELF, and others that are platform-specific. The original purpose of the auxv was to provide the ELF interpreter (ld.so) with information it needs in order to bootstrap.

skissane 6y ago
> IIRC it's not true for a.out executables on Linux I was surprised to discover a.out support is still there in the kernel [1]. There has been talk on LKML about whether to remove it [2] – apparently it has accumulated regression bugs (particularly in the area of core dumping) which nobody has noticed and fixed, which is the inevitable fate of code that hangs around for decades after everybody stops using it – but it still hasn't been removed yet. [1] https://github.com/torvalds/linux/blob/master/fs/binfmt_aout.c https://github.com/torvalds/linux/blob/master/fs/binfmt_aout... [2] https://www.lkml.org/lkml/2019/3/5/389 https://www.lkml.org/lkml/2019/3/5/389

TallGuyShort 6y ago

Huh - I remember using `char env` as the third parameter to main. After a quick Googling, it would seem that's a GCC-specific thing. Surprised there's a Linux-specific (or ELF-specific, as another commented) convention other than that one.

jlokier 6y ago
It isn't specific to GCC at all. It's widespread among unixes historically (and they generally have their own C compiler which is not GCC), and it was mentioned in the C89 standard. However, it is not part of standard C or POSIX/SUS. https://stackoverflow.com/a/10321474 https://stackoverflow.com/a/10321474
jwilk 6y ago
HN's comment monster ate your asterisks. :-( It should be: char **env
- TallGuyShort 6y ago
  Ah ha - now there's an argument in favor of the `char *env[]` notation!

rvnx 6y ago

Your post is the reason I like HN :) Thanks for sharing

saagarjha 6y ago

GDB also uses it to figure out where the binary is slid in memory (it reads /proc/pid/auxv, though, not the stack). AT_HWCAP is particularly useful on ARM because as far as I understand the feature registers are normally not readable by userspace and this is probably the easiest way to grab it on Linux.

1vuio0pswjnm7 6y ago

It is nice to see some BSD asm for a change (I know, someone will probably say this is about C, not asm). If one is hoping to learn anything about assembly language from reading the internet, most material found will focus on Linux or Windows. Even the HN comments on a blog post about BSD asm are about Linux.