Security Model Distinction between DCBI and DCBA

Two Historically familiar CMOs pose significant security problems that have made them increasingly unpopular:

• Invalidate Discarding Dirty Data
  • historic IBM POWER Architecture DCBA - Data Cache Block Invalidate
• Allocate Cache Line without Reading or Zeroing
  • historic IBM POWER Architecture DCBA - Data Cache Block Allocate
  • usually replaced by cache line zero cache block zero instructions such as DCBZ or CLZERO

Both have security holes in that they can expose data belonging to other privilege domains.

But the ways in which this can happen give them significantly different security properties:

Securing INVALIDATE/DISCARD

INVALIDATE/DISCARD throws out clean or dirty data in the caches. I.e. it can only expose values that were in that same (physical) line. This is a security hole if a memory buffer was allocated to one process, which may have stored secrets in it, and then deallocated from that process and reallocated to a new process - If the operating system performing such a reallocation did not zero and then cache flush the memory buffer. Zeroing the memory buffer is insufficient, because INVALIDATE/DISCARD and expose the value before it was zeroed. Flushing whenever memory buffers are reallocated in this manner hurts performance, if invalidate is not an operation that the new privilege domain can use.

This points to how to use INVALIDATE/DISCARD securely: if the operating system knows that it overwrites and then flushes all memory being reallocated in this manner.

In an HPC system dedicated to running a single application, this might always be the case.

But even in a general purpose Linux system running multiple user processes, the US could do this safely. If it is willing to make the necessary performance trade-off.

Some secure/general purpose systems perform this naturally: not only do they overwrite memory moving between users, they also want overwrite memory in DRAM, to reduce remanence attacks.

There are other issues with INVALIDATE/DISCARD, such as loss of non-determinism, or at least microarchitecture and timing dependent behavior that makes debugging difficult. But the performance improvement can be achieved in a relatively simple manner even for general-purpose Linux systems, at the cost of slowing down memory reallocation between processes.

security DCBA

DCBA, pack line allocate without reading, i.e. reusing whatever garbage the cache, possibly from previous privilege domains, is less constrained. Whereas INVALIDATE/DISCARD/DCBI and only expose data that was in the same (physical) cache line, DCBA 10 expose data that belonged to any cache line, any (physical) address, that might occupy the same storage within the cache,

So as to avoid the temptation to try to reason about limited or specific cache line associativity is nice is, I argue that it is best to think about the worst case: imagine that the caches are fully associative. DCBA, then, essentially means that the data in any physical address can be exposed in a new physical address.

This means that simple strategies like zeroing and cache flushing when a page of memory is reallocated from one process to another will not work for DCBA.

DCBA can only be secured when you can guarantee that no physical address, that might possibly be in the cache, contains secrets that you do not want to appear under the new address.

This is a hard constraint to satisfy. But it might be possible:

E.g. if you have physically isolated, cellular, systems with no memory sharing. only one process per partition. any system code within such a partition cannot contain secrets. Perhaps a bit far-fetched, but arguably possible in HPC systems,

Slightly more flexible, but uglier: you might allow OS code containing seekers to be present in such a partition, but you might configure the system such that such code can never be placed in a cache. I.e. you might make such system code non-cached, non-prefetchable, etc. while this sounds far-fetched, it is in fact the security model for systems that Change the physical memory map, bank switching or enabling DRAM banks, when changing certain privilege modes. E.g. Intel SMM when the SM RAM was required to be uncached. Not a nice security model, but it is one that has occurred at several times in history.

would it ever make sense to do this?

• Securing INVALIDATE/DISCARD/DCBI is not that hard* Requiring only changes the memory reallocation code in the operating system.

whether it makes performance sense or not, is workload dependent.

The performance trade-off is:

• reducing memory traffic for unnecessary writebacks
• cache flushes when reallocating memory across privilege domains
• cache flushes when clearing secrets in memory

On embedded systems - and I consider that some HPC systems are really embedded systems, where most of the workload is a single application, or when memory is seldom reallocated from one privileged domain to the other,\ this might make sense.

• Securing DCBA* is harder,

because it can expose any value that might possibly have been cached, at any address

 I can imagine it might be done for certain embedded systems, but it is certainly much harder.

The performance benefit is:

• making cache line reads unnecessary for DCBA

although it might still be necessary to perform some cache operation to maintain coherency.

Moreover, it is now common to deprecate DCBA operations in favor of DCBZ, zero cache line operations. These can avoid the unnecessary cache line reads, at the cost of zeroing memory in the, but with the benefit of having deterministic behavior.

Similar optimizations can be imagined for Safer INVALIDATE,