Researchers from the University of Rochester have created TimeCache, an approach to system security claimed to protect against side-channel attacks like evict+reload and Spectre, without the usual deleterious impact to performance.
2018 wasn’t a great year for chip-makers or their users, with the unveiling of a range of novel attacks levelled against the very design changes introduced to boost performance over the years. Known as Meltdown and Spectre, the vulnerabilities exist in the processors themselves and allow for processes to either access or infer the contents of memory used by other processes, accessing everything from passwords to cryptographic keys.
While the flaws themselves are hardware-based, the patches have arrived in microcode and software. Unfortunately, but unsurprisingly given the vulnerability existing in hardware designed to boost performance, this means they can slow down certain workloads. Even after the patches, new vulnerabilities exploited by side-channel attacks are being discovered all the time, including a proof-of-concept attack released by Google back in March this year.
TimeCache’s creators – Divya Ojha and Sandhya Dwarkadas from the University of Rochester’s Department of Computer Science – claim it could be the answer. Targeting the specific sub-class of side-channel attacks against cache carried out by shared software, TimeCache is claimed to offer perfect protection with a tiny performance impact, while keeping all of the lovely benefits of sharing things in the first place.
Performance and protection, together at last
“Our defence against timing side channels through shared software retains the benefits of allowing processes to utilise the entire cache capacity of a shared cache,” the pair explained in a paper presented at the ACM/IEEE 48th Annual International Symposium on Computer Architecture (ISCA). “[It] allows cache and memory pressure reduction through data deduplication and copy-on-write sharing.”
The core concept behind TimeCache is that it incorporates knowledge of prior cache line access, so that a given process’s first access to cache is delayed. This means it is not possible to infer whether another process running on the same system has requested the same data first.
“We achieve our goal,” the researchers explained, “by implementing per-process cache line visibility so that the processes do not benefit from cached data brought in by another process until they have incurred a corresponding miss penalty. The solution works at all the cache levels without the need to limit the number of security domains, and defends against an attacker process running on the same core, on a another hyper-thread, or on another core.”
Hardware modifications required
There’s a catch, of course. TimeCache can’t be implemented purely in software, and requires hardware modifications with the addition of a per cache line, per hardware context security bit dubbed an “s-bit”; a per cache line timestamp; a shift register; and a bit-serial timestamp-parallel comparison logic block with transpose gate and bitline peripherals in order to speed the comparison of timestamps.
These modifications add their own overhead, one which could be felt in the very environments where shared-software security is of most interest: the data centre.
“The total number of s-bits [required] can be significant for the LLC [Last Level Cache] in server-class processors,” the team admitted, pointing to methods already used for scaling coherence directories which could be applied to TimeCache to “reduce area overhead to O(log(n)) as opposed to n bits per cache line.”
To prove the concept, the researchers tested TimeCache using the gem5 architecture simulator. The system proved able to defend against apparent information leakage in a microbenchmark test, an active attack against the GnuPG version of the RSA security algorithm using the flush+reload attack, which worked on both real-world hardware and in simulation without TimeCache, but was blocked when it was implemented. This demonstrated that its implementation did not add any additional side channels which could be exploited.
The performance impact was negligable. Testing with the SPEC2006 and PARSEC benchmarks revealed an average overhead of just 1.13 per cent – a small impact for what appears to be comprehensive protection against an entire class of attacks.
Getting TimeCache to users
The TimeCache approach may end up appearing in free and open-source architectures before anyone using proprietary chips gets a sniff.
“To fully evaluate CPU design changes, researchers need access to simulation environments on different abstraction levels, as well as the full RTL sources,” claimed Stefan Wallentowitz, Professor at Munich University of Applied Sciences and director of RISC-V and the non-profit FOSSi Foundation dedicated to building up the community and ecosystem surrounding free and open-source silicon, in response to the paper.
“In contrast to proprietary alternatives, free and open-source silicon and the RISC-V ecosystem are providing many of these components today, enabling researchers to evaluate their ideas through all abstraction layers, and even share their implementations for others to reproduce and build upon,” he added.
“In terms of application developers protecting against Spectre-style vulnerabilities, the best approach is to abstract the protection away from the developers,” opined application security expert Sean Wright on the potential impact of the TimeCache techique. “By this, I mean embed the protection within the framework, operating system or have easy-to-use libraries.”
He continued: “Developers are often under pressure to deliver new functionality and don’t have the time to spend attempting to implement some form of security protection mechanism, let alone have the sufficient knowledge to do so.”
More details on TimeCache, which can be used alongside other defences, including cache randomisation, are found in this PDF copy of the paper: “TimeCache: Using Time to Eliminate Cache Side Channels when Sharing Software.” ®