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.
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.