On Wed, Jun 16, 2021 at 01:42:17PM +0000, David Laight wrote:
This patch mitigates some techniques that leak internal state due to table hash collisions.
As you say below it isn't really effective...
Actually it's Amit's attack which is really effective against anything that is not 100% random. And as you mentioned yourself in another thread, full randomness is not desirable as it can result in big trouble with ID collisions, especially when limited to 16 bits only. The only remaining factor to act on is thus the number of buckets to reduce the effectiveness of the attack.
Why should my desktop system 'waste' 2MB of memory on a massive hash table that I don't need.
In the patch's defense, it only consumes 2MB when the physical RAM is >= 16GB.
Right, but I've 16GB of memory because I run some very large applications that need all the memory they can get (and more).
Then by all means if your system is so tightly sized, buy this extra 2 MB DRAM stick you're missing, and install it next to your existing 16GB one.
Security-wise, this approach is not effective. The table size was increased to reduce the likelihood of hash collisions. These start happening when you have ~N^(1/2) elements (for table size N), so you'll need to resize pretty quickly anyway.
You really have to live with some hash collisions.
Absolutely, and that's the principle, that at some point it costs enough to the attacker for the attack to not be affordable or at least be easily detectable. All this for 1/8192 of your total RAM in the worst case, you will not notice more than when some fields are added to certain important structures and probably much less than when you simply upgrade whatever lib or binary. And probably that you forgot to reduce the amount of RAM dedicated to the video in your BIOS and can salvage no less than 32MB there!
Willy