How to interpret the checking result?

zjp-CN commented 6 days ago

I ran RAP on its test case uaf_drop, and got this analysis in logging form.

$ cd tests/uaf_drop && cargo rap -uaf 

7:47|RAP-FRONT|INFO|: Start cargo-rap
     Removed 0 files
7:47|RAP-FRONT|INFO|: Execute cargo clean.
7:47|RAP-FRONT|INFO|: Search local targets for analysis.
7:47|RAP-FRONT|INFO|: Find a new pakage: "uaf_00".
7:47|RAP-FRONT|INFO|: Running rap for target bin:uaf_00
    Checking uaf_00 v0.1.0 (/home/runner/work/dockerfiles/dockerfiles/tests/uaf_drop)
7:47|RAP-FRONT|INFO|: Execute after_analysis() of compiler callbacks
7:47|RAP-FRONT|INFO|: query_mop: Some("::main")
7:47|RAP-FRONT|INFO|: Meaning of output: 0 for ret value; 1,2,3,... for corresponding args.
7:47|RAP-FRONT|INFO|: Some("::fmt::{impl#2}::new_v1"),DefId(2:10533 ~ corea458::fmt::{impl#2}::new_v1)
7:47|RAP-FRONT|INFO|: [(0,2)]
7:47|RAP-FRONT|INFO|: Some("::mem::manually_drop::{impl#0}::new"),DefId(2:1943 ~ corea458::mem::manually_drop::{impl#0}::new)
7:47|RAP-FRONT|INFO|: [(0,1)]
7:47|RAP-FRONT|INFO|: analysis done
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.33s

I've read the RAP book, but nothing related is found.

For the context, I'm writing os-checker a tool running a collection of checkers targeting Rust crates, and reporting bad checking results and statistics. It successfully integrates lockbud and mirai, and I'm trying to integrate RAP into it.

I thought there would have been a structured result like json to be easily parsed and contain the information like lines & columns in source code pointing out the problems.

I've maintained a fork of RAP, made a precompiled release for it and got the above result in CI.

I'd much appreciate for your reply.

zjp-CN commented 6 days ago

I think RAP doesn't report the UAF bug for uaf_drop, which is a bug of RAP.

I see RAP indeed reports UAF for uaf_lifetime though.

e9276f9b91e34c5ee794be496dd7d67

hxuhack commented 6 days ago

Yes, the yellow color indicates a bug, while the white-colored information represents the alias analysis results. As you have seen, we have designed several PoCs in the tests folder, categorized under drop, dangling, and df, to assess the capabilities and limitations of our tool. As you've noted, it currently does not handle the uaf_drop case. We are actively working to enhance our tool to detect this bug in the near future.

hxuhack commented 6 days ago

The issue should have been fixed now with Pull 54.

zjp-CN commented 5 days ago

Thank you for the explanation and quick fix.

the yellow color indicates a bug

Why is a bug logged as info level instead of error level?

And I notice the logger is initialized with hard-encoded info level. Could an environment variable like RAP_LOG be supported?

https://github.com/Artisan-Lab/RAP/blob/8fcfa832e0cb8fce4edf630f326ecc2b82fdbde5/rap/src/bin/cargo-rap.rs#L378

hxuhack commented 5 days ago

The use-after-free (UAF) bug is reported at the warning level using the rap_warning! macro.

Regarding the initialization failure, I believe the expect method usually writes its error messages to standard error (stderr).

I agree with your suggestion to use an environment variable to control log and debugging messages. We plan to support this feature, hopefully by next week. By the way, if you could submit a pull request, I would really appreciate it.

zjp-CN commented 5 days ago

可能我没有表达清楚。我的意思是，一个 bug 记录到 error 级别的日志可能更好，而不是当前的 warn 级别。（我有注意到 error 日志有一个 exit 版本，但我不是指使用它，因为可能在规模不大的仓库上，显示所有检查结果而不是第一个 bug 上退出更好）

我明天可以提交支持环境变量的 pr，因为目前的日志太多，我只需要搜索 bug 级别的输出。

谢谢。

Artisan-Lab / RAP

How to interpret the checking result? #53