Levine's /Linkers and Loaders/ is a great book, but it's still in print, and this is an unauthorized copy.
The author's home page (https://www.iecc.com/linker/) used to host a PostScript version for download, but it no longer does, now saying: "Chapters were available in an excessive variety of formats, but are not any longer due to chronic piracy."
These days there is lots of information about linkers and loaders to be had without violating Levine's copyright; see https://www.toolchains.net/ for many links.
A JIT is a machine for turning logic bugs into memory unsafety. Rewriting a JIT in Rust won't eliminate logic bugs and won't guarantee memory safety for the binary output of the JIT (as distinct from the JIT implementation itself).
Even with a verifiably random key, Dual EC is still unacceptable.
First, because its output has unacceptable biases [1,2].
Second, because its presence allows an attacker to create a difficult-to-detect backdoor simply by replacing the key, as apparently happened with Juniper NetScreen devices [3,4].
[2] Berry Schoenmakers and Andrey Sidorenko, Cryptanalysis of the Dual Elliptic Curve Pseudorandom Generator, May 2006. Online: https://eprint.iacr.org/2006/190.pdf
[3] Stephen Checkoway, Jacob Maskiewicz, Christina Garman, Joshua Fried, Shaanan Cohney, Matthew Green, Nadia Heninger, Ralf-Philipp Weinmann, Eric Rescorla, and Hovav Shacham, A Systematic Analysis of the Juniper Dual EC Incident, October 2016. Online: https://www.cs.utexas.edu/~hovav/dist/juniper.pdf
[4] Ben Buchanan, The Hacker and the State, chapter 3, Building a Backdoor. Harvard University Press, February 2020.
It would not help at all. See (all of, but especially) section 5.4 of N. Carlini, A. Barresi, M. Payer, D. Wagner, and T.R. Gross, "Control-Flow Bending: On the Effectiveness of Control-Flow Integrity," in proc. USENIX Security 2015, https://www.usenix.org/conference/usenixsecurity15/technical...
"Best Practices (BP) papers, up to 10 pages. Suitable papers are those that provide an integration and clarification of ideas on an established, major research area, support or challenge long-held beliefs in such an area with compelling evidence, or present a convincing, comprehensive new taxonomy of some aspect of secure development. Such a paper would be marked with the prefix 'BP:' in the title, and would need to provide new insights, although it could draw upon prior work." [https://secdev.ieee.org/2018/papers/#best-practices]
Per the call for papers [https://www.usenix.org/conference/usenixsecurity23/call-for-...], that means the paper would have been submitted for review by June 7, 2022, accepted for publication as of September 2, 2022, and had the final ("camera-ready") version uploaded by October 4, 2022.
The conference itself won't take place until August of this year.
See also the closely related "DVFS Frequently Leaks Secrets: Hertzbleed Attacks Beyond SIKE, Cryptography, and CPU-Only Data," presented at Oakland last week: https://www.hertzbleed.com/2h2b.pdf
See also the closely related "DVFS Frequently Leaks Secrets: Hertzbleed Attacks Beyond SIKE, Cryptography, and CPU-Only Data," which will be presented at Oakland today: https://www.hertzbleed.com/2h2b.pdf
I don't think Juniper used BSAFE in ScreenOS -- they seem to have put together their own Dual EC implementation on top of OpenSSL, sometime around 2008. (This doesn't change your point, of course.)
... has not been (effectively) patched against, as it happens. Maybe in December!