Zero Filling - Part VII - Hyperthreads a related problem

A long time ago, about two years back, I was unhappy about zero filling. I am still unhappy about it.

One of the main arguments for zero filling is security. On a multi-user system you enter your password, which invariably is then stored if even temporarily in RAM. A clever process of a different user could now eventually swap in the used memory with this password and you are as they say compromised. (There is also an argument for it in a single user situation, I ignore this for this entry)

The same problem happens to an extent with hyperthreading. The fix for that appears to be, that hyperthreads are only allowed for processes of the same user. The same reasoning could be applied to memory as well. If memory is returned to the OS, then it need not be zeroed out if the owning process of the next allocation is by the same user.

This would make things quite a bit faster in some cases.