Take advantage of AT_RANDOM for seeding the PRNG

[daurnimator]

Restores some code from 53987c9/#7482

• Avoid calling the Gimli permute function so we don't pull Gimli into every executable.
• Add an opt-out in the form of root.use_AT_RANDOM_auxval

[jedisct1]

I still feel like this is not a good idea. Or, maybe the switch should be set to false by default.

If dlopen()ed libraries do the same thing, they will end up with a static, all zero seed.

If our Zig code is used as a library, an application may also have cleared it before.

This also constrains us to a 128 bit seed. Which is fine, but 256 bit doesn't hurt, especially with a new and non-ideal permutation.

[daurnimator]

If dlopen()ed libraries do the same thing, they will end up with a static, all zero seed.

If our Zig code is used as a library, an application may also have cleared it before.

The code is only run when zig is the entrypoint: the call site is inside of posixCallMainAndExit.
For other contexts (e.g. a library) then it won't get run and nothing changes from the status quo.

an application may also have cleared it before.

See:

    // don't use AT_RANDOM if it has been zeroed out
    if (mem.allEqual(u8, ptr, 0)) return;

Though due to the aforementioned reason, this should never be hit by "normal" code.

[jedisct1]

Also, clearing it is nice, but with SSP turned on, a copy is still present.

[jedisct1]

The code is only run when zig is the entrypoint: the call site is inside of posixCallMainAndExit.

That doesn't address the issue of libraries possibly using AT_RANDOM being dlopen()d by a Zig application.

[daurnimator]

with SSP turned on, a copy is still present.

oh? howso/where?

That doesn't address the issue of libraries possibly using AT_RANDOM being dlopen()d by a Zig application.

1. isn't that prevented by us overwriting AT_RANDOM?
2. dlopen in particular is (currently) only available when linking libc; which usually means that our _start code won't be used (and hence won't use AT_RANDOM).

[LemonBoy]

What's the problem you're trying to solve here? The default state for the TLSPRNG is set to .unitinialized and it will be properly seeded the first time it is used.

[jedisct1]

oh? howso/where?

Isn't this in fs:0x28?

The stack canary has to persist somewhere till the end of the process. And if what we clear is not a copy, this kinda defeats the purpose of SSP.

But I may be completely wrong here; this is in a glibc context, maybe we don't even support SSP otherwise.

Still, that change doesn't make me comfortable at all and I'm not convinced that it solves any actual problem.

UPDATE: Quick note on canaries.

On x86_64 anything compiled with stack protection expects the canary (a copy of the AT_RANDOM value) at fs:0x28. This includes C files compiled by Zig, that have stack protection on by default.

But when we don't link with libc, we currently don't initialize this, ending up with an all zero canary, making stack protection useless.

[daurnimator]

UPDATE: Quick note on canaries.

On x86_64 anything compiled with stack protection expects the canary (a copy of the AT_RANDOM value) at fs:0x28. This includes C files compiled by Zig, that have stack protection on by default.

But when we don't link with libc, we currently don't initialize this, ending up with an all zero canary, making stack protection useless.

hmmm. I didn't know this. Where is this documented?