Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data.

Divya Ojha

dblp:159/6818 · DBLP profile ↗
← Back
3ranked-venue papers
2as first author
2since 2021 · last 2023
0000-0002-3814-2421ORCID · corroborated

Domains — the database's venue-derived domains; a paper can count in several

Systems, architecture and hardware · 2 · 2 first-author · 2 since 2021Security and privacy · 1Software engineering, systems software and programming languages · 1 · 1 first-author · 1 since 2021

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Computer architecture, parallel and distributed computing, and storage systems
3 papers
Memory systems · 76% Processor architecture and microarchitecture · 24%
Network and information security
3 papers
Hardware security and side channels · 100%

Topics — the 10 heaviest of 10, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Hardware security and side channels
side-channel attack
1.222023
Preventing Coherence State Side Channel Leaks Using TimeCache · IEEE Trans. Computers 2023
TimeCache: Using Time to Eliminate Cache Side Channels when Sharing Software · ISCA 2021
Hardware security and side channels › side-channel attack
cache side-channel attacks
0.712023
Preventing Coherence State Side Channel Leaks Using TimeCache · IEEE Trans. Computers 2023
Memory systems
cache design
0.712023
Preventing Coherence State Side Channel Leaks Using TimeCache · IEEE Trans. Computers 2023
Memory systems › cache management
secure cache
0.712023
Preventing Coherence State Side Channel Leaks Using TimeCache · IEEE Trans. Computers 2023
Processor architecture and microarchitecture
speculative execution
0.522023
Restricting Control Flow During Speculative Execution · CCS 2018
Preventing Coherence State Side Channel Leaks Using TimeCache · IEEE Trans. Computers 2023
Hardware security and side channels
cache side channel
0.512021
TimeCache: Using Time to Eliminate Cache Side Channels when Sharing Software · ISCA 2021
Memory systems
cache
0.512021
TimeCache: Using Time to Eliminate Cache Side Channels when Sharing Software · ISCA 2021
Memory systems › cache › multiprocessor cache
shared cache
0.512021
TimeCache: Using Time to Eliminate Cache Side Channels when Sharing Software · ISCA 2021
Processor architecture and microarchitecture › speculative execution › speculative execution attacks
spectre
0.212023
Preventing Coherence State Side Channel Leaks Using TimeCache · IEEE Trans. Computers 2023
Hardware security and side channels
side-channel countermeasures
0.112018
Restricting Control Flow During Speculative Execution · CCS 2018

Methods — techniques the papers use, named apart from their topics

gem5 simulation · 2.3timestamp comparison · 1.0software-based mitigation · 0.7control flow restriction · 0.7
YearPublicationVenuePosition
2023 Preventing Coherence State Side Channel Leaks Using TimeCache
abstract
Cache side channel attacks in the presence of shared memory have been used to extract cryptographic keys and enclave data, and are used by Spectre variants for leaking speculatively loaded data. Timing side channels exist in shared caches due to the difference in response latency of cached and uncached data. In prior work, we presented TimeCache, a cache design that prevents side channel exploits from reuse of shared memory. In this work, we extend TimeCache to also defend against attacks that exploit coherence states. TimeCache allows all running applications to use the entire cache, avoiding the need for partitioning in order to effect timing isolation. A per-process caching context prevents cache hits on data filled by another process. A novel bit-serial timestamp-parallel comparison logic allows low-overhead update of stale caching contexts. The defense is suited to all caches levels, and defends against an attacker running on any core. We evaluate TimeCache using the gem5 simulator to show that it is capable of preventing both reuse attacks and an attack based on coherence state leak. The average performance overhead for SPEC2006 is 1.13%, and for PARSEC and SPLASH is 0.46%.
Divya Ojha, Sandhya Dwarkadas
IEEE Trans. Computers1
2021 TimeCache: Using Time to Eliminate Cache Side Channels when Sharing Software
abstract
Timing side channels have been used to extract cryptographic keys and sensitive documents even from trusted enclaves. Specifically, cache side channels created by reuse of shared code or data in the memory hierarchy have been exploited by several known attacks, e.g., evict+reload for recovering an RSA key and Spectre variants for leaking speculatively loaded data.In this paper, we present TimeCache, a cache design that incorporates knowledge of prior cache line access to eliminate cache side channels due to reuse of shared software (code and data). Our goal is to retain the benefits of a shared cache of allowing each process access to the entire cache and of cache occupancy by a single copy of shared software. We achieve our goal 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. Our design achieves low overhead by using a novel combination of timestamps and a hardware design to allow efficient parallel comparisons of the timestamps. 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 hyperthread, or on another core.Our implementation in the gem5 simulator demonstrates that the system is able to defend against RSA key extraction. We evaluate performance using SPEC2006 and PARSEC and observe the overhead of TimeCache to be 1.13% on average. Delay due to first access misses adds the majority of the overhead, with the security context bookkeeping incurred at the time of a context switch contributing 0.02% of the 1.13%.
Divya Ojha, Sandhya Dwarkadas
ISCA1
2018 Restricting Control Flow During Speculative Execution
abstract
Speculative execution is one of the key techniques that modern processors use to boost performance. However, recent research shows that speculative execution can be used to steal sensitive data. We present a software-based solution to mitigate Spectre attacks by restricting the control flow of speculatively-executed instructions.
Zhuojia Shen, Jie Zhou 0022, Divya Ojha, John Criswell
CCS3