On Wed, 6 Apr 2022 at 10:29, Robert Haas <robertmhaas@gmail.com> wrote:
>
> I think that the paper shows that, under the right set of
> circumstances, a timing-based attack is possible here.
Generally any argument that an attack is infeasible is risky and
usually leads to security professionals showing that surprisingly
difficult attacks are entirely feasible.
However I think the opposite argument is actually much more
compelling. There are *so many* timing attacks on a general purpose
computing platform like Postgres that any defense to them can't
concentrate on just one code path and has to take a more comprehensive
approach.
So for example a front-end can add some stochastic latency or perhaps
padd latency to fixed amount.
Perhaps postgres could offer some protection at that level by e.g.
offering a function to do it. For most users I think they're better
off implementing it at the application level but some people use
database stored functions as their application level so it might be
useful for them.
Something like pg_sleep_until_multiple_of('50ms') which looks at the
transaction start time and calculates the amount of time to sleep
automatically.
--
greg
