I've been thinking that the problem that makes Meltdown/Spectre possible is a synchronization problem between the use of the cache by all running processes and invalidating the cache when switching tasks so that the contents of the cache for a process don't exist when switching and running to another process.
I've been thinking that the best solution to prevent memory leakage between processes through the cache would be to provide a new set of API functions that allow user-space programs to control their usage of the cache, for example, to disable the cache entirely for memory pages allocated with malloc(), etc., so that variables/buffers with sensitive data reside only in RAM but never in the cache, and thus making it impossible to leak memory of that sensitive data from another process. For example, 32-bit protected mode of the x86 includes a bit in each page entry that allows to specify whether that memory page will use the cache or not: http://wiki.osdev.org/File:Page_table.png http://wiki.osdev.org/Paging The new cache-controlling API functions could mainly allow a program to control this bit, control cache flushes, etc., so that, given the virtual addres of a buffer or variable, the kernel can resolve that virtual address to mark the page entry to disable it from the cache. If a program uses that for memory that it knows that will contain user/password login data, or encrypted network traffic, then Also, a program loader could be created to invoke programs as with sudo, that when run, makes all data pages, and optionally code pages, to have their use of the cache disabled in the page table entries so that existing programs can run securely without the possibility of cache leaks if for example an user wants to run a high-security script. Programs running as the root user could also have their usage of the cache for data sections disabled for security reasons. It could be an option that could be enabled or disabled, and there could be private data sections in an executable that could specify whether to use the CPU cache or not. DMA memory is very fast and it's supposed to have its usage of the cache disabled, so this case where we might want to disable the cache to prevent sensitive data to be copied in random places of the cache could prove more efficient than other ways to patch the kernel and applications, but it would require a new set of API functions that would allow user programs to enable/disable their cache for code/data globally, as well as for variables configured by the program with that API, and also flushing the cache when done dealing with sensitive data. The multitasking and paging code of the kernel could still need to be improved to make sure that the cache doesn't contain any data from the current program, when switching to another one, to prevent having data that shouldn't reach another program when switching tasks.