hovav

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.

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.

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.

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

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

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

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

Indeed, the History of Documented Unix Facilities [https://github.com/dspinellis/unix-history-man] says a vi(1) man page first appeared in 2BSD, and vi is implemented (as part of ex, with a 1979 copyright) in 2BSD src/ex, with the main routines at src/ex/ex_vmain.c: https://github.com/dspinellis/unix-history-repo/blob/BSD-2-S...

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

X. Ren et al., "I See Dead µops: Leaking Secrets via Intel/AMD Micro-Op Caches," in proc. ISCA 2021: https://cseweb.ucsd.edu/~tullsen/isca2021.pdf

It's listed as a summer deadline accepted paper for USENIX Security 2023: https://www.usenix.org/conference/usenixsecurity23/summer-ac...

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

(It's citation 68 in the Hot Pixels paper.)

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

Steven Galbraith's Mathematics of Public Key Cryptography: https://www.math.auckland.ac.nz/~sgal018/crypto-book/crypto-...