So how secure can non-assembly code truly ever be against timing attacks?
First of all, let me state that this is a tricky subject.
The simplest method is of course to do away with the lookup tables or and other components that are vulnerable to timing attacks. So when a cipher designed, it should require a minimum of vulnerable components. And during execution a minimum of vulnerable constructs should be used to be absolutely secure. For instance AES can be implemented in various ways - some are more secure than others when it comes to side channel attacks. This is all stated by DJB in the paper as well.
It is extremely hard for a native library to control cache timings too. Generally libraries are generally not constructed for a specific CPU. It may be almost impossible to control and measure how the cache handling is performed - or even how much cache is present. So in that sense machine code is (almost) as vulnerable as non-native code.
One way to conquer such complexity is to have a CPU instruction, co-routine or co-processor perform AES. Such an instruction can be designed from the ground up to be invulnerable to timing attacks. If designed well it is completely independent from cache and memory and thus from side channel attacks that rely on them.
The fact that non-native code cannot directly control the instructions and memory addresses doesn't mean it cannot control it at all. Often you can still analyze what happens at a lower level. For instance, an array in Java is not stored in reverse. You know from the specifications that it will be a single, sequential block of data somewhere in memory.
If you are stuck with things like tables then you have various options. You can for instance make sure that an attacker simply does not have enough access to perform an attack. It may be hard for an attacker to put a table on two different pages in memory, for instance.
It may also be hard for an attacker to gain enough timing information. Almost any timing information may be extracted using statistics. But just like brute forcing, it may be that the amount of data required is too high for a practical attack.
Unfortunately this page is not large enough to discuss all measures that can be taken against side channel analysis, and then validate if they are secure for machine code and high level languages. Yes, there are constructs that are valid for both (RSA blinding is probably the most well known one). Is RSA blinding enough to show that code is secure against timing attacks? Probably not.
Note that pretty often the answer to the question is: we haven't tested the code against side channel attacks and hope our algorithms and protocols are secure enough.
One way to battle this in an organization is to buy a HSM (or TLS offloader or other secure system) which should be secure against side channel attacks, basically side stepping the issue completely. These things can be very expensive, but if you require the highest protection against side channel analysis you may have a lot to lose as well.
