Re: glibc qsort() vulnerability

From: Andres Freund <andres(at)anarazel(dot)de>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Mats Kindahl <mats(at)timescale(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers mailing list <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: glibc qsort() vulnerability
Date: 2024-02-09 19:24:23
Message-ID: 20240209192423.dlfm7x7dvhqakmwe@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mats Kindahl 2024-02-09 19:26:48 Re: glibc qsort() vulnerability
Previous Message Dave Cramer 2024-02-09 19:23:46 Re: [PATCH] Add native windows on arm64 support