What is the logic of fixpoint comuptation about cwe_checker HOT 2 CLOSED

About fixpoint computations in general: We compute properties of programs at specific execution points. We want these properties to hold true regardless of the execution path that was taken to reach that program point. The point of fixpoint computations is that one computes these properties in a path-dependent manner, but then continues computation until a fixpoint is reached. If one can reach a fixpoint, then the result will hold true regardless of the execution path taken to the program point, despite being computed with path-dependent methods.

For the function signatures this is very important, because other analyses depend on the correctness of this computation. For the CWE-119 check on the other hand, it is a choice to use fixpoint computations. There are other approaches one can use here with different advantages and drawbacks. A somewhat abstract motivation is that in the far future we may be able to prove the absence of certain bug classes if we do not find any CWEs with a fixpoint-based analysis approach. But in the cwe_checker we are still far away from that.

If you want to read up on the topic I recommend looking at the literature regarding compiler optimizations like dead code removal, expression propagation, and the like, as they are usually also implemented using fixpoint computations. Unfortunately, I do not maintain a list of good beginner literature for the topic at the moment.

Why the param_access_stubs and the stubbed_variadic_symbols are generated at runtime: In theory, you can make the two computation functions const, which would mean that they are computed at compile time. The const fn story of Rust is still evolving and I have not checked whether newer versions of Rust allow this already. However, the runtime cost is negligible anyway.

from cwe_checker.

Thank you for the detailed explanation!! It is quite clear now.

from cwe_checker.