Function Ptrs
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.
The function set attribute can be initialized using the $FSET$ definition. For example, the definition $FSET fs = func1, func2, func3;$ followed by a use $(int \rightarrow int)*fs \ \ fptr;$ denotes a function pointer $fptr$ whose targets are the functions $func1, func2, func3$.
Optimization
Optimization by eliminate function pointer checks:
Simple typing rules that can statically check the call graph contained in the pointer analysis in most cases;
Add runtime checks where static checking is not possible;
A more precise call graph by adding extra run-time checks only at call sites where more precision is required.
PAFSET attribute in addition to FSET attribute: - FSET: If two function pointers have the same FSET attribute, they potentially call the same set of functions. - PAFSET: To differentiate between the input call graph and the call graph given by the pointer analysis, use PAFSET to identify the function poiner from pointer analysis.
- Enforcing Alias Analysis for Weakly Typed Languages, TR, 2005. ↩
If you could revise
the fundmental principles of
computer system design
to improve security...
... what would you change?