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@mit.edu> napsal:
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.
From:
Kyotaro Horiguchi Date: Subject:
Re: pg_receivewal fail to streams when the partial file to write is not fully initialized present in the wal receiver directory
