[Cryptography] Speculation considered harmful?

[Henry Baker]

At 06:14 PM 1/6/2018, Tony Arcieri wrote:
>On Sat, Jan 6, 2018 at 2:28 PM, Viktor Dukhovni <cryptography at dukhovni.org> wrote:
>There's not much point in debating on this list largely impractical
>seat-of-the-pants CPU-design changes.  Making the cache transactional
>is I expect almost certainly far too complex a design option.
>
>Measures to improve process isolation are likely much more realistic.
>
>A slightly more tangible approach is partitioning the cache around protection domains:
>
>https://eprint.iacr.org/2005/280

IMHO, one basic problem is that once you have data caching, array references can no longer be depended upon to execute in constant time.  This "feature" is used to extract private/secret info from other processes.

There used to be DSP's with instructions that you could utilize to *bypass the cache* -- both for loading and storing.  Although these instructions took longer, the processor could do other things in the time between the load and actually trying to utilize the result.

These *cache-bypassing* capabilities weren't put there for security or privacy, but for *efficiency* in real-time DSP operations.  If you knew you were operating on a very long vector of data values (i.e., so long that it couldn't possibly fit into the cache), then it would be pointless to poison the data cache with all of these values which the compiler (and/or programmer) knows will not be used again before finally being flushed, and there *IS* other valuable data in the cache that *will* be used -- e.g., by high speed interrupts.

Yes, there are DSP architectures with multiple registers sets, multiple caches, etc., for handling such real-time interrupts, but these architectures don't scale very well, and the software investment is usually not preserved when the next version of the chip comes out.