Let rand = main as usize (2022)

&gt; For those expecting to the usual Rust guard rails, it&#x27;s surprising that the compiler allows casting between arbitrary raw pointer types outside of an unsafe block. This feels really dangerous— even though we can&#x27;t do anything with the pointer outside of an unsafe block, creating a raw pointer usually implies that an unsafe block will eventually do something with it. I kind of wish that this pointer casting required unsafe, just because this code should send up red flags, and probably deserves a close look during code review.<p>I think the general philosophy is that unsafe only demarcates potentially unsound code whereas casting between different pointers isn&#x27;t technically unsound even though it can cause unsoundness in unsafe code if done incorrectly. I agree with the author that casting between unrelated pointer types should probably be considered unsafe but would probably require a new edition which would mean Rust 2027 at the earliest (assuming someone is motivated enough to push it through the bureaucracy).

It&#x27;s not quite the same, but it made me think of how in the Atari 2600 game <i>Yars&#x27; Revenge</i>, the TV static-like &quot;neutral zone&quot; in the middle of the screen is literally just the game&#x27;s code from the ROM taken as a bitmap and placed in the right part of the console&#x27;s playfield. I think they XOR together two different sections of code, scrolling in different directions.

As an aside getauxval(3) allows access to AT_RANDOM which is &quot;the address of sixteen bytes containing a random value.&quot;

There&#x27;s also the good old trick of measuring duration between two instants and using that as a (crude) randomness source.<p>Also on Linux there&#x27;s the AT_RANDOM entry in the aux vector, which provides any program with 16 random bytes.

&gt; It&#x27;s debatable whether this is effective at turning away attacks, but that&#x27;s the goal, and ASLR is enabled on almost every operating system in use today.<p>It&#x27;s not debatable at all, ASLR is a significant barrier to attacks.<p>Quote from a random hacking book:<p>&gt; By doing so, it makes it significantly harder for an attacker to predict the location of specific processes and data, such as the stack, heap, and libraries, thereby mitigating certain types of exploits, particularly buffer overflows.<p><a href="https:&#x2F;&#x2F;book.hacktricks.xyz&#x2F;binary-exploitation&#x2F;common-binary-protections-and-bypasses&#x2F;aslr" rel="nofollow">https:&#x2F;&#x2F;book.hacktricks.xyz&#x2F;binary-exploitation&#x2F;common-binar...</a>

Might having correlated random variables (in this case, rand and the address of main) unintentionally cause vulnerabilities like the Debian OpenSSL incident [0]?<p>[0] <a href="https:&#x2F;&#x2F;lists.debian.org&#x2F;debian-security-announce&#x2F;2008&#x2F;msg00152.html" rel="nofollow">https:&#x2F;&#x2F;lists.debian.org&#x2F;debian-security-announce&#x2F;2008&#x2F;msg00...</a>

It&#x27;s basically the XKCD random number generator: <a href="https:&#x2F;&#x2F;xkcd.com&#x2F;221&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;221&#x2F;</a><p>Also on Windows, randomized address space layout changes only on reboot.

FTA: Even in the best circumstances, a program can only acquire one random value this way<p>Can it?<p><pre><code> let rand = if(fork() == 0) {main as usize} else {std::process::exit(0)} </code></pre> (For those who wonder: I know this code has ‘some’ issues)