Re: glibc qsort() vulnerability - Mailing list pgsql-hackers

From Andres Freund
Subject Re: glibc qsort() vulnerability
Date
Msg-id 20240209192423.dlfm7x7dvhqakmwe@awork3.anarazel.de
Whole thread Raw
In response to Re: glibc qsort() vulnerability  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Dave Cramer
Date:
Subject: Re: [PATCH] Add native windows on arm64 support
Next
From: Mats Kindahl
Date:
Subject: Re: glibc qsort() vulnerability