LWN: Comments on "getauxval() and the auxiliary vector"

erratum: x86 cpufeatures location

georg.s — Fri, 29 Dec 2017 19:43:10 +0000

Actually, the x86 details are defined in

arch/x86/include/asm/cpufeatures.h

and not in

arch/x86/include/asm/cpufeature.h (sic!)

getauxval() and the auxiliary vector

oak — Tue, 13 Nov 2012 11:09:26 +0000

Nice. Yet another way for programs to find out on what kind of a platform they're running at runtime.

(If everything would use it instead of reading the /proc/self/auxv file directly, it would be nice, now it just means that tools like SB2 and user-space Qemu have yet another thing they need to catch & override, but at least this new method is easier to override.)

getauxval() and the auxiliary vector

BenHutchings — Mon, 15 Oct 2012 19:21:16 +0000

Sorry if I am outright clueless, but it would be very interesting if it can be used for multiarch scenarios.

Multiarch and biarch requite that each coexisting architecture has a distinct dynamic linker.

Maybe to simplify mixing x64 and x86 in a distribution-agnostic fashion, or even more interesting; Not only to run the foreign code but also link to a library of foreign architecture.

This is not possible even with thunking of function calls (very expensive if you have to make 32/64-bit mode switches) as the different architectures have different memory layouts.

getauxval() and the auxiliary vector

dashesy — Mon, 15 Oct 2012 17:48:18 +0000

Sorry if I am outright clueless, but it would be very interesting if it can be used for multiarch scenarios. Maybe to simplify mixing x64 and x86 in a distribution-agnostic fashion, or even more interesting; Not only to run the foreign code but also link to a library of foreign architecture.

getauxval() and the auxiliary vector

mina86 — Fri, 12 Oct 2012 16:44:26 +0000

I don't think that's a real problem. The random bytes are not available to outside applications (unless they trace it like debuggers or strace do, but in this case, it would be easier to just read the random seed or just overwrite the seed).

getauxval() and the auxiliary vector

mina86 — Fri, 12 Oct 2012 16:42:10 +0000

With this piece of code: https://gist.github.com/3880154 and glibc 2.11 I'm able to get some value of AT_RANDOM. Checking whether glibc simply leaves it be or it fills it with some other random data is left as an exercise for the reader. ;)

getauxval() and the auxiliary vector

njwhite — Fri, 12 Oct 2012 12:03:31 +0000

(with apologies for the embarassing levels of ignorance this likely displays)

Could other applications read your auxiliary vector, and hence the seed you're using? Would this then have much effect on the guessability of subsequent random numbers?

HWCAP human readable on my 32-bit Centrino

pr1268 — Thu, 11 Oct 2012 21:46:19 +0000

I tried sleep with LD_SHOW_AUX=1 set, and my AT_HWCAP values were the human-readable processor capabilities I get when I cat /proc/cpuinfo. Plus, I had an extra entry at the beginning, AT_SYSINFO.

FWIW I have GLIBC version 2.13 (which implies the getauxval() call isn't available to me). Just sharing my experiences here; thanks for the article!

getauxval() and the auxiliary vector

luto — Thu, 11 Oct 2012 21:20:29 +0000

Can glibc also give me a good random seed? Take AT_RANDOM, use it to seed some simple PRNG, keep the first chunk of output for a stack canary, and give me the rest. (The PRNG could be as simple as using an MGF or some large-output hash. Something like SHA-3 could be used for this purpose, since Keccak can produce any amount of output, sequentially.)

Currently AFAIR glibc zeros AT_RANDOM after using it for its own nefarious purposes.