stack_protector: Add tunable to bypass random cookies

[cem]

Summary

Add the new tunable, "security.stack_protect.permit_nonrandom_cookies," in
order to continue boot with insecure non-random stack cookies if the random
device is unavailable.

For now, enable it by default. This is not safe. It will be disabled by
default in a future revision.

[cem]

Add CTASSERT that nitems(__stack_chk_guard) matches our expectations.

[cem]

Tinderbox passes. I'd appreciate expediency on this one, if possible.

[emaste]

I'm fine with this as an immediate fix for the installer/VM boot issues.

Please expand the commit message a little bit, in that this change is effectively restoring the status quo prior to rS346250.

[imp]

this is a reasonable stopgap, approved with the understanding that there will be follow on work to allow MD sources of entropy, like RDSEED on x86 etc

[delphij]

For a stopgap fix I think it's fine. Note that it's probably better to derive __stack_chk_guard from SHA512 of something that we change often (e.g. __FreeBSD_version) concatenate with something that potentially varies, like getcyclecount(), for the fallback guard data: these are not secure random numbers, but would make it harder for an attacker to develop more generic smashing attack.