~ wrote:
We would probably need to be able to fully reproduce the bugs or we might be solving nothing if we don't fully know what's happening and how to avoid it.
As I said I would start by doing the following:
- Disable the CPU cache fully. Most OSes here don't use the cache due to their beginner-level simplicity. When we learn to use the cache efficiently, we can selectively invalidate the whole cache and wait a time for the cache flush operation to complete, when we don't want data leak. We could add cases to the kernel, like flushing the cache every 15 or 30 seconds, or when using hashing/criptography APIs, for the things that would trigger a full cache flush.
- Provide APIs to set the program configuration to invalidate the cache every time it's switched by the multitasking system, and also a flag to invalidate it if it's run as root/administrator.
This measure should be something that could be enabled or disabled for efficiency, but in all cases we must understand it to make it possible, for example, to come up with highly optimized Assembly tricks that take advantage on the behavior of a CPU and that uses it to implement robust code that intrinsically avoids this problem by the way it uses the cache usefully, not just trying to stop an undesired side effect of the behavior of the CPU implementation. Always implement for functionality, not merely to patch flaws which would actually make for a poorer code.
The solution proposed here won't work. Simply flushing caches wont be enough as the kernel does not necessarily regain control over the processor between the speculative instructions executing and the code extracting the data executing. On a single core platform, the attacker could simply use transactional memory instructions, and when using multiple cores, extraction of the data can be done in parallel with the speculative execution stream, meaning that the data will have been leaked before the kernel has had any chance to respond.
As for disabling the caches, even simple hobby OSes use these extensively. The cache infrastructure of the processor is mostly transparant to user programs, even the kernel, and the performance benefits are ENORMOUS (as in a factor 100 or more in execution speed these days). While you could use this as a mitigation, the fact that you are using it will most likely relegate you to the amateur space so thoroughly that I would no longer worry about meltdown anyway.
NOTE: This is just my personal analysis. Anything here could be complete bullcrap. DO NOT USE THIS INFORMATION TO MAKE DECISIONS FOR CRITICAL HARDWARE/SOFTWARE SYSTEMS. THE AUTHOR DISCLAIMS, TO THE EXTENT PERMISSIBLE BY LAW, ANY RESPONSIBILITY AND OR CULPABILITY FOR HARM CAUSED BY INACCURACIES IN THE ABOVE INFORMATION.