vasilito
cb424d7448
verify-patch-sanity.py validates every active recipe .patch has internally- consistent hunk line counts — catching the 'malformed patch at line N' failure at commit/CI/preflight time instead of hours into a cook. This cycle hit that class three times (qtwaylandscanner, sddm, xwayland), each only discovered when cookbook tried to apply the patch. Running it across the repo found 29 latent malformed patches (validated against GNU patch: e.g. relibc/P3-sysv-ipc reproduces 'malformed patch at line 22'). They were harmless only because they sit in vendored recipes (baked, not re- applied) — but would fail on any version-bump re-derivation. --fix recounts the hunk headers (body untouched) and repaired all 29. Wired into build-preflight.sh (Phase 1.0D) and redbear-ci.yml, with a unit test (test-patch-sanity.sh). Skips archived/legacy trees and unvalidatable formats (empty placeholders, bare-@@ git hunks).
57 lines
2.3 KiB
ReStructuredText
57 lines
2.3 KiB
ReStructuredText
==================================
|
|
Stack Safety Analysis
|
|
==================================
|
|
|
|
|
|
Introduction
|
|
============
|
|
|
|
The Stack Safety Analysis determines if stack allocated variables can be
|
|
considered 'safe' from memory access bugs.
|
|
|
|
The primary purpose of the analysis is to be used by sanitizers to avoid
|
|
unnecessary instrumentation of 'safe' variables. SafeStack is going to be the
|
|
first user.
|
|
|
|
'safe' variables can be defined as variables that can not be used out-of-scope
|
|
(e.g. use-after-return) or accessed out of bounds. In the future it can be
|
|
extended to track other variable properties. E.g. we plan to extend
|
|
implementation with a check to make sure that variable is always initialized
|
|
before every read to optimize use-of-uninitialized-memory checks.
|
|
|
|
How it works
|
|
============
|
|
|
|
The analysis is implemented in two stages:
|
|
|
|
The intra-procedural, or 'local', stage performs a depth-first search inside
|
|
functions to collect all uses of each alloca, including loads/stores and uses as
|
|
arguments functions. After this stage we know which parts of the alloca are used
|
|
by functions itself but we don't know what happens after it is passed as
|
|
an argument to another function.
|
|
|
|
The inter-procedural, or 'global', stage, resolves what happens to allocas after
|
|
they are passed as function arguments. This stage performs a depth-first search
|
|
on function calls inside a single module and propagates allocas usage through
|
|
functions calls.
|
|
|
|
When used with ThinLTO, the global stage performs a whole program analysis over
|
|
the Module Summary Index.
|
|
|
|
Testing
|
|
=======
|
|
|
|
The analysis is covered with lit tests.
|
|
|
|
We expect that users can tolerate false classification of variables as
|
|
'unsafe' when in-fact it's 'safe'. This may lead to inefficient code. However, we
|
|
can't accept false 'safe' classification which may cause sanitizers to miss actual
|
|
bugs in instrumented code. To avoid that we want additional validation tool.
|
|
|
|
AddressSanitizer may help with this validation. We can instrument all variables
|
|
as usual but additionally store stack-safe information in the
|
|
``ASanStackVariableDescription``. Then if AddressSanitizer detects a bug on
|
|
a 'safe' variable we can produce an additional report to let the user know that
|
|
probably Stack Safety Analysis failed and we should check for a bug in the
|
|
compiler.
|