OK let me explain to you why cache over sensitive information is irrelevant, consider the meltdown case:
Code:
mov rax, [kernel_address]
and rax, 1
mov rbx, [user_address + rax * 0x100]
On line one you access a faulty address, due to a bug in CPU, the permission is checked in async manner, exception will fire upon the instruction retire. Inside the CPU, that instruction will be break up into micro-op including 2 operations: fetch [kernel_address] into register file, alias result to rax. This instruction will run (and cause exception) with or without cache enabled.
Now with speculated execution, the following 2 lines will get executed, and using the internal register file even rax will get discard later (by not aliasing to rax). With [user_address] cache enabled, such speculation will cause a cache-effect on the user data.
Long time later you handle the exception gracefully and return rax = 0, then by checking if [user_address + 0x100] is in the cache you deduce if the bit is one.
The only way (in this direction) to totally avoid this is disable cache over [user_address], which is impractical.
The Boundary Check Bypass CVE works similar way and you cannot protect by disable cache over sensitive data.