Re: glibc qsort() vulnerability
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Mats Kindahl <mats@timescale.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers mailing list <pgsql-hackers@lists.postgresql.org>
Date: 2024-02-09T19:24:23Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Use new overflow-safe integer comparison functions.
- 3b42bdb47169 17.0 landed
-
Introduce overflow-safe integer comparison functions.
- 6b80394781c8 17.0 landed
-
Replace calls to pg_qsort() with the qsort() macro.
- 5497daf3aa2a 17.0 landed
-
Switch over to using our own qsort() all the time, as has been proposed
- 6edd2b4a91bd 8.2.0 cited
Hi, On 2024-02-10 00:02:08 +0500, Andrey Borodin wrote: > > Not really in this case. The call is perfectly predictable - a single qsort() > > will use the same callback for every comparison, whereas the if is perfectly > > *unpredictable*. A branch mispredict is far more expensive than a correctly > > predicted function call. > > Oh, make sense... I did not understand that. But does cpu predicts what > instruction to fetch even after a call instruction? Yes, it does predict that. Both for branches and calls (which are just special kinds of branches in the end). If you want to find more about this, the term to search for is "branch target buffer". There's also predictions about where a function return will jump to, since that obviously can differ. Modern predictors aren't just taking the instruction pointer into account, to predict where a jump/call will go to. Tey take the history of recent branches into account, i.e. the same instruction will be predicted to jump to different locations, depending on where the current function was called from. This is important as a function obviously can behave very differently depending on the input. > These cpus are really neat things... Indeed. Greetings, Andres Freund