# Is having AES tables on a distinct physical page enough to avoid cache timing attacks?

Reading about typical cache timing attacks, they seem to be based on intentional eviction of cache lines and timing how long an operation takes. It seems as if those attacks rely upon these tables being hardcoded constants in read-only sections of an executable, and are therefore subject to sharing memory pages.

If you ensure that your AES tables are on physical pages that are private to your process, is that enough to thwart timing-based attacks? In this situation, an attacker running as a normal-privileged process on the same machine would not be able to perform such tricks as clflushing the cache lines containing the table.

Note that this technique also requires that the contents of the pages are also unique, not just private: some operating systems might notice memory pages with identical contents and coalesce them to a single physical page as copy-on-write.

As a side note: When process is attacker running as a normal-privileged process, it has access to all other normal-privileged processes in many OSes (for example Windows), so attacker can simply read key.
• Cache lines seem to be 64 bytes these days. Would reading all four cache lines of the S-box each time it's accessed and using e.g. cmovxx to select the desired answer among the four work? This is definitely more expensive than the 4-byte lookup table, though. Jan 14 '17 at 2:24
• Well, you have no guarantee that cache line is 64byte (but you can retrieve it from system, afaik). It would work (cmov doesn't cache or predict), but standard practice is to interleave data then (for example first write all first bits of result, then every second bit etc. - then you always read whole buffer). But honestly, that is why AES is so terrible in software. If you can, replace it with for example ChaCha20 (no buffers, quite immune to timing attacks, fast and bigger security margin than AES). Jan 14 '17 at 14:04