Chris Browne wrote:
Lukas Kahwe Smith <smith@pooteeweet.org> writes:
Chris Browne wrote:
Cacheing tends to make lots of operations run more quickly, ergo in
"about the same time," for the small, simple queries.
Well but since the attack is based on inserting data, wouldnt this
likely cause cache invalidation in many cases?
Perhaps to some degree, but it is not at all clear that it will be
material. If they're adding new tuples to a predictable set of
tables, in large quantity, this will tend to lead to a pattern of:
- Allocating a new page (which will throw in a little bit of variance)- Adding several tuples to that page
The index work will tend to draw a bunch of pages for the relevant
tables into cache, which should tend to stabilize, unless they're
actually throwing so much data at the system that they're really
making the DB larger, at which point I'd expect the "real" data to
start to disappear, washed out by their data.
Dwelling on this issue *way* more than I think it deserves:
Any noise in the signal, including caching, vacuuming, other queries, etc., can be averaged out, given a sufficient number of samples. Even if the signal is very small and the noise is very large. The more noise there is (relative to the signal), the more samples you need to average the noise out, but the existence of noise doesn't disprove the theoretical capability of the attack.
However, it does introduce a pragmatic concern- basically that the necessity for large numbers of samples (queries) in order to overcome the noise problem is itself a very noticeable effect. If you need to spend days, weeks, or even months hammering a database server to get enough samples in order to average out the noise, even the most obtuse admin is likely to notice (if for no other than reason than all of the other users of the database complaining about the slow performance).
Brian
