All pointers in Type-Unknown pools are checked.
int to pointer are runtime checked to ensure in the right pool.int1All pointers derived from array indexing operations need run-time check (2006 PLDI1), regardless of TK or TU. More about array bound checking.
All function pointers need runtime check before being used. (2005-SAFECode-TR: function pointer)
Runtime check methods:
poolcheck(ph, A, o): verifies that the address, A, is contained within the set of memory ranges assigned to pool, ph, and has the correct alignment for the pool’s data type (or for the field at offset o, if o $\neq$ 0).SAFECode summary in SVA SOSP 20072:
Prevents uninitialized reference: data flow analysis for local variables & initilize allocated memory to illegal address for all other pointer variables.
Prevents array bound violations: extension of the Jones-Kelly approach for detecting array bounds violations. Uses a separate run-time search tree (a splay tree) in each pool to record all array objects at run-time, and looks up pointer values in this table to check for bounds violations.
Ensures type-safety in TK pools.
Ensures CFI by generating native code itself & preventing write to code pages & using runtime checks to ensure that indirect function calls match the CFG at compile time.
Guaranttee the soundness of the operational semantics, given the correctness of analysis information (i.e., the call graph, point-to graph, and type information for TH partitions)
Reference: Enforcing Alias Analysis for Weakly Typed Languages, TR, 2005. Runtime Check on Function Pointers (From 2005 TR1) The call graph is simply checked explicity at each indirect call site ( some could be removed). Call graph is one of the input of SAFECode. The call graph is represented in the input type system by adding a function set attribute called $fs$ in Figure 2 to each function pointer type, making explicit the set of possible targets for that function pointer.
Reference1 Extension to JK and JKRL. Summary of Jones-Kelly from 2006ICSE1: Jones-Kelly inserts the following checks (ignoring any later optimizaiton) on each arithmetic operation involving a pointer value: JK1. check the source pointer is not the invalid value (-2); JK2. find referent object for the source pointer value using the table; JK3. check that the result pointer value is within the bounds of this referent object plus the extra byte.
If you could revise
the fundmental principles of
computer system design
to improve security...
... what would you change?