Re: Practical Timing Side Channel Attacks on Memory Compression

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 <stark(at)mit(dot)edu> napsal:

> On Wed, 6 Apr 2022 at 10:29, Robert Haas <robertmhaas(at)gmail(dot)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
>
>