OS Checks: User Reviews (Manual Review)¶

Some OS-related checks can reach situations where the tool cannot fully decide whether the code is compliant, for example:

A function call target cannot be resolved (e.g. indirect calls / unsupported call syntax).
The source code of a referenced function is not available (e.g. 3rd-party binary contribution).

In these cases, the result can require manual review.

RTA-SQF supports a user review list (sometimes called function whitelisting) that lets you declare specific functions as manually reviewed. When a match is found, the tool can stop following the call tree at that function and treat the unknown part as already reviewed.

This is intended to reduce “manual review required” findings caused by missing information, while still reporting real rule violations that can be proven from the available code.

What You can Configure¶

You configure reviewed functions by providing text files that contain glob patterns. Patterns can be:

global for all OS AoUs (common list), and/or
specific to one OS AoU.

Where to Place the Configuration Files¶

RTA-SQF looks for review configuration files inside the output folder (the directory given by --out-dir). The search expects that the files are located in a subfolder called config/whitelists.

If a required configuration file is not found, RTA-SQF falls back to built-in defaults and may extract default files into the expected folder. A practical workflow is:

Run the check once with your intended --out-dir.
Look for the extracted default configuration files under the config/whitelists subdirectories of the output folder.
Copy/edit them for your project and rerun.

File Names¶

Common configuration (applies to all OS AoUs):

ETAS_RTACAR_SM_OS_AllRules.txt

AoU-specific configuration:

ETAS_RTACAR_SM_OS_<RuleNumber>.txt

Examples:

ETAS_RTACAR_SM_OS_181.txt
ETAS_RTACAR_SM_OS_187.txt
ETAS_RTACAR_SM_OS_206.txt

File Format¶

Each non-empty, non-comment line defines one pattern entry.

Lines starting with # are comments.
Empty lines are ignored.

Each entry has up to three fields separated by @:

FunctionNameGlob@ImplementationFileGlob@TranslationUnitGlob

Only the first field is required.

FunctionNameGlob (required) Glob pattern for the function name.
ImplementationFileGlob (optional) Glob pattern for the function implementation file path.
TranslationUnitGlob (optional) Glob pattern for the translation unit path.

If you omit optional fields, they match “any”.

Glob Syntax (Summary)¶

RTA-SQF uses standard glob-style matching:

* matches any sequence of characters
? matches a single character
[abc] matches one character from a set
For paths, ** can be used to match any directory depth

Examples¶

Allow by function name only:

# Exact function name match in any file
MyReviewedFunction

# Prefix pattern for any function starting with "ProjectSafeWrapper_"
ProjectSafeWrapper_*

#All functions implemented in files named "debug.c"
*@**/debug.c

# All functions implemented in the only "test/debug.c" file
*@**/test/debug.c

# All functions implemented in any ".c" file directly under the "src" folder
*@**/src/*.c

# All functions implemented in any ".c" file under a "src" folder at any depth
*@**/src/**/*.c

# All functions implemented in any ".c" file under a "src" folder at the project root
*@src/**/*.c

It is also possible to restrict by the translation unit (as the 3rd field). This is useful, for example, if the analyzed project uses static functions defined in header files: you can use the translation unit field to allow them only when compiled in the expected context.

# Allow functions in "utils.h" only when compiled in "utils.c"
*@**/utils.h@**/utils.c

How RTA-SQF Applies the Rules¶

For an OS AoU run:

the common file ETAS_RTACAR_SM_OS_AllRules.txt is applied, and
the AoU-specific file (for example ETAS_RTACAR_SM_OS_187.txt) is applied.

All matching entries are considered.

In reports (SARIF/HTML), reviewed parts are shown as Reviewed call stack information, and the review entry is recorded as an accepted external suppression with a justification like:

Reviewed by user with rule:'<your function pattern>'

Recommended Workflow¶

Run rta-sqf os with a stable --out-dir.
If you get “manual review required” findings caused by missing source/indirect calls, identify a suitable boundary function that you have manually reviewed.
Add a matching entry to:
- ETAS_RTACAR_SM_OS_AllRules.txt if it should apply to all OS AoUs, or
- the specific ETAS_RTACAR_SM_OS_<RuleNumber>.txt if it is AoU-specific.
Rerun and confirm the finding is now treated as reviewed.

Good Practices¶

Prefer precise patterns (add file / translation-unit constraints) to avoid suppressing too broadly.
Keep project-specific review files under version control.
Treat the review list as a safety-relevant artifact: document why the function is safe in your project process.

Limitations¶

User reviews are meant to address analysis limitations (unknown call targets, missing source code).
They are not intended to hide real violations that can be proven from the available code.