josh@agliodbs.com (Josh Berkus) writes:
>> Lots of "maybes" here, but certainly lots of things *likely* to happen
>> that will throw off attempts to time things. Configuration would also
>> have big effects on timings; more cache would generally make some
>> operations take less time, thereby drawing timings together, and
>> cutting down on the variations that the "attacker" is trying to
>> measure.
>
> Heh, I never thought our unpredictable response times would be an asset ...
Hey, there's a much more optimistic way to regard this...
A lot of this comes from the developments that diminish the
"spikiness" of system behaviour, generally diminishing variations in
performance, which tend to make system behaviour *more* predictable,
not less.
Cacheing tends to make lots of operations run more quickly, ergo in
"about the same time," for the small, simple queries.
We saw this when we put v8.1 into production; in general, response
times got more predictable, indeed, more nearly constant. And that's
the sort of tendancy that will cut down on the would-be variations
that the attacker, in the described scenario, would be trying to look
for.
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://linuxdatabases.info/info/spreadsheets.html
Rules of the Evil Overlord #161. "I will occasionally vary my daily
routine and not live my life in a rut. For example, I will not always
take a swig of wine or ring a giant gong before finishing off my
enemy." <http://www.eviloverlord.com/>
