SearcharxivSearch

arXiv subjects

Akash Gaonkar

Publications and source records attributed to Akash Gaonkar.

3 recordsLinked to original sources

SecIC3: Customizing IC3 for Hardware Security Verification

Recent years have seen significant advances in using formal verification to check hardware security properties. Of particular practical interest are checking confidentiality and integrity of secrets, by checking that there is no information flow between the secrets and observable outputs. A standard method for checking information flow is to translate the corresponding non-interference hyperproperty into a safety property on a self-composition of the design, which has two copies of the design composed together. Although prior efforts have aimed to reduce the size of the self-composed design, there are no state-of-the-art model checkers that exploit their special structure for hardware security verification. In this paper, we propose SecIC3, a hardware model checking algorithm based on IC3 that is customized to exploit this self-composition structure. SecIC3 utilizes this structure in two complementary techniques: symmetric state exploration and adding equivalence predicates. We implement SecIC3 on top of two open-source IC3 implementations and evaluate it on a non-interference checking benchmark consisting of 10 designs. The experiment results show that SecIC3 significantly reduces the time for finding security proofs, with up to 49.3x proof speedup compared to baseline implementations.

cs.CR

Application-Level Validation of Accelerator Designs Using a Formal Software/Hardware Interface

Ideally, accelerator development should be as easy as software development. Several recent design languages/tools are working toward this goal, but actually testing early designs on real applications end-to-end remains prohibitively difficult due to the costs of building specialized compiler and simulator support. We propose a new first-in-class, mostly automated methodology termed "3LA" to enable end-to-end testing of prototype accelerator designs on unmodified source applications. A key contribution of 3LA is the use of a formal software/hardware interface that specifies an accelerator's operations and their semantics. Specifically, we leverage the Instruction-Level Abstraction (ILA) formal specification for accelerators that has been successfully used thus far for accelerator implementation verification. We show how the ILA for accelerators serves as a software/hardware interface, similar to the Instruction Set Architecture (ISA) for processors, that can be used for automated development of compilers and instruction-level simulators. Another key contribution of this work is to show how ILA-based accelerator semantics enables extending recent work on equality saturation to auto-generate basic compiler support for prototype accelerators in a technique we term "flexible matching." By combining flexible matching with simulators auto-generated from ILA specifications, our approach enables end-to-end evaluation with modest engineering effort. We detail several case studies of 3LA, which uncovered an unknown flaw in a recently published accelerator and facilitated its fix.

cs.AR

Conflict-Aware Replicated Data Types

We introduce Conflict-Aware Replicated Data Types (CARDs). CARDs are significantly more expressive than Conflict-free Replicated Data Types (CRDTs) as they support operations that can conflict with each other. Introducing conflicting operations typically brings the need to block an operation in at least some executions, leading to difficulties in programming and reasoning about correctness, as well as potential inefficiencies in implementation. The salient aspect of CARDs is that they allow ease of programming and reasoning about programs comparable to CRDTs, while enabling algorithmic inference of conflicts so that an operation is blocked only when necessary. The key idea is to have a language that allows associating with each operation a two-state predicate called {\em consistency guard} that relates the state of the replica on which the operation is executing to a global state (which is never computed). The consistency guards bring three advantages. First, a programmer developing an operation needs only to choose a consistency guard that states what the operation will rely on. In particular, they do not need to consider the operation conflicts with other operation. This allows purely {\em modular reasoning}. Second, we show that consistency guard allow reducing the complexity of reasoning needed to prove invariants that hold as CARD operations are executing. The reason is that consistency guard allow reducing the reasoning about concurrency among operations to purely {\em sequential reasoning}. Third, conflicts among operations can be algorithmically inferred by checking whether the effect of one operation preserves the consistency guard of another operation.

cs.DC