Notices by Daniel J. Bernstein (djb@mastodon.cr.yp.to)

Interested in compiler bugs? Here's one for x86 in e.g. gcc-14.2.0 -O1 -m32: void foo(const void *x) { if (isnan(*(float *) x)) printf("%x\n",*(int *) x); } int main() { int u = 0x7f987654; printf("%x\n",u); foo(&u); return 0; } (using math.h, stdio.h). Workaround: volatile.

@wingo Sorry, how exactly is accessing a NaN via a float pointer supposed to be undefined behavior?

@wingo @barubary OK, here's a do-everything-via-memcpy display of the same gcc bug (again gcc -O1 -m32, after including string.h, stdio.h, math.h): void foo(void *x) { int i; if (isnan(*(float *) x)) memcpy(&i,x,4); printf("%x\n",i); }
void bar(void *x) { int i; memcpy(&i,x,4); printf("%x\n",i); }
int main() { float x = __builtin_nansf(""); foo(&x); bar(&x); return 0; }

@wingo @barubary It's obvious what the compiler writer was thinking, namely that FLD followed by FST would just be a copy of the original data. It's also clear how this breaks real code. All we're discussing is whether the C standard (foolishly) allows this bug; I don't see how it does.

@dalias Does the void * in the standard interfaces for memcpy etc. look like nonsense? I expect typical C programmers to read it as a hint that the function is at least partially polymorphic (whereas the traditional char * is now more of a hint that the function wants byte arrays or byte strings).

Anyway, this gcc bug looks like it comes from someone simply not understanding that FLD-FST isn't equivalent to a copy. This is compiler confusion about machine-language semantics, not about C types.

@dalias Feel free to change void * to float * in this code and you'll see the same FLD-FST gcc bug appearing. However, the void * is a helpful hint for human readers.

The gcc/clang excuse for changing program behavior, often introducing bugs and security holes (see https://www.usenix.org/system/files/usenixsecurity23-xu-jianhao.pdf), is performance. But a new paper https://web.ist.utl.pt/nuno.lopes/pubs/ub-pldi25.pdf modifies clang to eliminate most (all?) such changes, and finds negligible effect on benchmarks.

@Pyrrhlin Specifically, they claimed that they "require (human) author names" rather than an "organization". But organizations are listed as authors of documents all the time (e.g.: https://web.archive.org/web/20250309024856/https://iacr.org/petitions/gaza_war.html); previous cryptographic research papers from organizations have appeared on eprint (e.g.: https://web.archive.org/web/20250130053518/https://eprint.iacr.org/2022/087.pdf); and published eprint policy says "any author" (https://web.archive.org/web/20240413134704/https://iacr.org/eprint/). It's clear that IACR's actual goal here is to suppress this particular new report, not to be consistent.

Pleased to announce PQConnect: https://www.pqconnect.net Easy-to-install software for your Linux box (more OSes coming later) to protect network applications against future quantum computers. Paper will appear at NDSS 2025. Joint work with @hyperelliptic, Jonathan Levin, Bo-Yin Yang.

@eliotlear OK, looks like time for Recusal 101: Do you think that it's okay for U.S. Supreme Court justices with conflicts of interest to not recuse themselves since there's more than one judge on the court? And it's okay for lower-court judges with conflicts of interest to not recuse themselves since there's an appeals process? Do you understand what the purpose of recusal is?

@eliotlear There you go again with these ridiculous "everyone" exaggerations. The actual issue at hand is an IETF security-area directorship being given to an employee of NSA, an organization with a policy and track record of sabotaging security standards.

@rsalz @eliotlear I gave an example earlier in the thread; but, again, the recusal obligation is triggered simply by the appearance of a conflict of interest. https://www.ietf.org/about/groups/iesg/iesg-coi-policy/ says "In cases where a clear conflict of interest exists, an Area Director should normally recuse". It doesn't say "Wait until the evidence of bad decisions is so overwhelming that you feel pressured to do what you would have done without this policy existing in the first place".

@eliotlear Your quote is fabricated. I said he (and others, including me) expressed concerns. Instead of answering, the NSA AD filed WG-creation forms as if discussion had settled. As for your "no industry or government participant" strawman: I'm talking specifically about NSA. That's an organization that internally asked whether cryptographic standards could be made "weak enough" for NSA to break, and that at last report had a cryptographic sabotage budget of a quarter billion dollars a year.

This year IETF appointed a "Security Area Director" whose August 2024 conflict-of-interest filing lists NSA as a source of income: https://www.ietf.org/about/groups/iesg/iesg-coi-policy/ Profile says retired from NSA "with 37+ years of service in Dec 2023", still "working as a Stand-by Active Reservist at NSA".

New blog post "Clang vs. Clang": https://blog.cr.yp.to/20240803-clang.html You're making Clang angry. You wouldn't like Clang when it's angry. #compilers #optimization #bugs #timing #security #codescans

Tracking down some TIMECOP alerts led to a 2021 gcc patch from ARM (https://gcc.gnu.org/git/?p=gcc.git;a=commit;f=gcc/match.pd;h=d70720c2382e687e192a9d666e80acb41bfda856) turning (-x)>>31 into a bool, often breaking constant-time code. Can often work around with (-x)>>30, and asm is safer anyway, but for portable fallbacks we need security-aware compilers.