Thanks for all of your opinions. I have almost the same feeling.
The best layer for mitigation should be probably a user application.
There can be arranged the correct data layout in the database, set up
access limit for the app, and many other mitigation mechanisms.
-Filip-
st 6. 4. 2022 v 17:24 odesÃlatel Greg Stark <st...@mit.edu> napsal:
> On Wed, 6 Apr 2022 at 10:29, Robert Haas <robertmh...@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
>
>
