> has already been patched against

... has not been (effectively) patched against, as it happens. Maybe in December!

Standard operating procedure for both the Chrome [https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s...] and Firefox [https://www.mozilla.org/en-US/about/governance/policies/secu...] bug tracking systems.

But the fix itself is public in both the Chrome [https://chromium.googlesource.com/chromium/src.git/+/36dbbf3...] and Firefox [https://github.com/mozilla/gecko-dev/commit/ac605820636c3b96...] source repos, and it makes pretty clear what the bug is.

Looks like this one only applied to windows. Here’s a link to the diff: https://chromium.googlesource.com/chromium/src.git/+/36dbbf3...

> Xiaogang (Cliff) Wang is listed as the principal investigator.

No, you are misreading the award abstract. Cliff Wang is the program manager at NSF who is the point of contact for the investigators.

Ah. Wrong box on the form. XiaoFeng Wang is in the Principal Investigator box.

Was NSF funding for the project cancelled?

It's not guaranteed. See section 7 of https://www.usenix.org/system/files/conference/usenixsecurit...

> power need[s] to be exploited locally

Not in the presence of DVFS, it turns out: https://www.hertzbleed.com/hertzbleed.pdf

Abersoft Forth for the ZX Spectrum inspired one of the classic books about Forth, Don Thomasson's /Advanced Spectrum FORTH/ (1984): https://archive.org/details/AdvancedSpectrumFORTH

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.

I suspect "chronic piracy" is an euphemism for "massive bandwidth usage".

Incidentally, the Internet Archive still remembers.

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).

Agreed. But the way you put it makes me wonder how many memory safety vulns have been found in JIT implementations (not the machine code they output).

Okay, but in this case software verification like with Coq or F* could help

Yes! See, e.g., Fraser Brown et al., "Towards a Verified Range Analysis for JavaScript JITs," in proc. PLDI 2020, https://www.cs.utexas.edu/~hovav/dist/vera.pdf

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].

--- [1] Kristian Gjøsteen, Comments on Dual-EC-DRBG/NIST SP 800-90, draft December 2005. Online: https://web.archive.org/web/20110525081912/https://www.math....

[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.

> Even with a verifiably random key

What's a "verifiably random" key?

"Verifiably random" means produced using a process where it isn't possible for you to know the outcome. In this case, saying "the key is [X], which is the SHA-2 hash of [Y]" would allow you to know that they couldn't choose [X] without breaking SHA-2.

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...