[ender341341]

the idea is that well written software would release memory as soon as possible so with it enabled you'd have the secret in memory for as little time as possible.

Though in my mind well written software should be zeroing the memory out before freeing if it held sensitive data.

[jamesfinlayson]

Yes I thought that was common practice - I remember reading patch notes for something years ago where the program had been updated to always zero the password buffer after checking that it matches (I think in some cases it was kept around for a bit).

[bhawks]

From a defense in depth perspective you definitely want the implementation to be robust (zero the memory after reading). However you should also consider:

1) abnormal program termination due to signals, memory pressure/oom killer, aborts in other threads serving different requests, and so on. These events could race with the memory zeroing.

2) bugs in the implementation where memory isn't zeroed in all paths

3) interactions between compiling, standard libraries, language runtimes and optimization passes causing memory zeroing to be skipped.

All these cases have happened time and time again in the wild. Hence having additional safety nets is useful.

These patches were endorsed by folks working on chromeos and Android security. I would suppose that they want them to put additional safeguards behind full disk encryption keys and may also be concerned with quality of implementation issues in 3rd party or vendor blobs.