Two ARM64-specific compiler optimization bugs, in GCC 15/16 and Rust, hit curl | Hacker News Reader

Two ARM64-specific compiler optimization bugs, in GCC 15/16 and Rust, hit curl

mastodon.social

52 pointstorutofu12 comments

Not actually confirmed as compiler bugs yet.

Here’s a similar bug where OpenSSL’s inline asm was wrong and probably only GCC was smart enough to try to exploit the bug:

https://github.com/openssl/openssl/pull/23233

Same for rust - could be UB in quiche that is getting exposed.

Can't even find an upstream compiler bug report not to mention a confirmation/patch. Doesn't look like the compiler output was analyzed at all either, they are just going by "-O3 results in valgrind warnings, -O2 doesn't".

It's not like compiler bugs are unheard of but they are rare enough that the base assumption should be that the bug is in your own code.

And not only is this blaming a compiler bug, which like sure, those do happen, it blames two compiler bugs in different programming languages. That's a red flag to me.

turns out it was just valgrind not handling a valid optimization correclty.

I call this UB exceptionalism. Your UB is bad and you need to fix it. My UB is a valid optimisation and the tools are producing false positives.

Valgrind only detects UB. We can do something for standard libraries that exploit this kind of UB - Valgrind replaces functions like strlcpy with its own versions that do not contain any UB. We can’t do that for all user libraries.

I remember that PR for similarly interesting reasons:

Someone on the pgsql-hackers@ mailing list noticed that, with a then-recent OpenSSL version on graviton, there were issues validating the "control file" of a PostgreSQL instance [0] (control files contain some basic ground truths about a cluster).

The report included a lot of detailed information about the program state, sufficient for me to figure out that one of the registers was definitely getting clobbered during the pg_strong_random() calls[1], but without access to the environment I couldn't prove whether it was the OpenSSL library, or a compiler bug.

A few days later an Apt developer was debugging the same issue from another direction, eventually figured out that this was caused by a typo in openssl's register restoration code (which was written in ASM introduced in the PR linked by parent post), and then submitted a PR to OpenSSL to fix the issue [2], now (presumably) for good.

[0] https://postgr.es/m/Z4VjonBTm6IG8mGa%40msg.df7cb.de

[1] https://postgr.es/m/CAEze2WiRijBaoeFgi1JvsZeO6qXvpYkh4ax1bUV...

[2] https://github.com/openssl/openssl/pull/26469

The social post links to this bug https://github.com/curl/curl/issues/23237

Thank you

Looks like a valid new optimization to me, which only fails on valgrind, which is a bit too strict with uninitialized values. In openssl's strlcpy. They'll deal with that.

Who are ‘they’? OpenSSL?

Of course, who else

It could have been either Valgrind or OpenSSL.

Reply on news.ycombinator.com