Pump
Q&A
How to init tags?
- LLM: developer writes rules in a special language; software handler computes the rule and generates mappings of tags (as policy)
- 2018sp-stack: Compiler + adding instructions into programs.
- 2018sp-stack: Lazy tagging (first write) + Lazy clearing (on all write, check only on read)
How to propagate tags?
- LLM: mapping of tags (policy rules) will be used to propagagte tags during execution of PUMP.
Is there any new instruction added to the ISA spec?
Is there any new instructions added to the binary?
How to add object type to it as in CHERI Domain?
Reference
RISC processor (Alpha): in-order implementation with a 5-stage pipeline suitable for energy-conscious applications.
gem5, generate instruction traces;
PUMP simulator, instr. traces;
Address-trace simulator, addr. traces;
Every word in a PUMP system is associated with a pointer-sized tag. memory, caches, registers including PC.
- simple metatdata can store directly in the tag;
- complex (unbounded) metadata can use tag as address of metadata in memory;
PUMP rules
(2014 HASP) The core architectural feature proposed is the PUMP – an architectural mechanism designed to enforce runtime policies.
- The PUMP should operate in parallel with the normal ALU computation to avoid slowing down the computation.
- PUMP Cache: To the hardware, the metadata tags are uninterpreted. Accordingly, the hardware does not compute rules. Instead, rules are cached in the hardware: the mapping between the inputs and outputs of rules.
- Software interpretation: when a rule is not found in the cache, it traps to a software handler that can resolve the rule and insert it into the hardware cache.
PUMP allows a programmer or system designer to create policies. A policy is defined as a functional mapping of a set of tags to another set of tags resulting in a collection of rules that implement some desired tracking and enforcement mechanism and also manipulate the tags.
Rules come in two forms: software – symbolic rules; and hardware – concrete rules.
Symbolic rules
opcode: (PC, CI, OP1, OP2, MR) --> (PC_new, R, allow?)
SAYS:
- rule matches on the given opcode + metadatas on PC, current instruction(CI), two operands (OP1, OP2), and if any, on memory read value (MR)
- on a match, right hand side determine wether instruction is allowd and how metadata should be updated on PC, and Result.
Concrete rules
A rule representation for efficient hardware implementation of symbolic rules.
Rule checking
- Instruction is issued;
- PUMP check if there is a rule that validates the current instruction:
- match against all rules;
- if match found, the cache returns the new tag of the PC and if needed, a tag for the instructions result;
- if no match, faults to PUMP miss handler:
- consults the symbolic rules via software handler;
- if allowed, new concrete rule will be inserted;
- if not allowed, security fault handler;
RISC-V Impl
Drapper, Dover, CoreGuard
Patents
US10261794B2