What is the status of `ScopeEnd` and `ScopeBegin`

Clang Frontend Static Analyzer
1

Recently, I tried to solve a use-after-free problem, which involves checking for dereferencing a pointer that points to freed stack memory, for example:

void su_use_after_block ()  { int* p=0; { int x=1; p=&x; } *p = 2;     }

First of all, I try:

void MyChecker::checkDeadSymbols(SymbolReaper &SymReaper,
                                      CheckerContext &C) const {
  ProgramStateRef State = C.getState();
  bool Changed = false;
  for (const MemRegion *R : State->get<WatchedStackLocals>()) {
    if (!SymReaper.isLiveRegion(R)) {
      State = State->remove<WatchedStackLocals>(R);
      State = State->add<InvalidStackRegions>(R);
      Changed = true;
    }
  }
  if (Changed)
    C.addTransition(State);
}

But the region of x is still alive. I know the reason now.

So I tried to use the cfg-scopes feature to get the information about x exiting the block, and I found that ScopeEnd does not seem to be handled.

So I want to know what the current status is. If it hasn’t been implemented yet, what should I do to implement this feature?

I’m extremely grateful.

2

Have you tried looking at the lifetime safety analysis? https://clang.llvm.org/docs/LifetimeSafety.html

It uses the CFGElement::LifetimeEnds markers. Those should be in a pretty good state. And the analyzer could also use them of you need your analysis implemented in the analyzer.

Indeed, the live/dead here does not mean whether the underlying storage is still there. But whether the value is reachable from the program state and could be read at a future program point.

3

Thank you!
But the CFGElement::LifetimeEnds doesn’t seem to have been processed as you can see above.

What should I do if I want to use it in a checker?

I am a beginner, thank you very much for your answer. :grinning_face_with_smiling_eyes:

4

You probably need to introduce a new callback. That can be a bit involved and a lot of plumbing. That being said, I think we eventually want to improve the analyzer’s understanding of lifetimes, so teaching the engine when the lifetime of certain regions end exactly would be quite useful!

So the right way forward might be not to just make these available for individual checks but to make the engine itself smarter. If you’d like some challenges :slight_smile:

5

Yes it looks like nobody has implement the checker callback for CFGLifetimeEnds because for now they’re ignored. You may need to make your own. Basically make your own ProcessLifetimeEnds() function and make it dig all the way down to your new checker callback invocation, same as other Process...() functions. And double-check that the LifetimeEnds markers are enabled in CFG::BuildOptions.

(If you want to make it fancy and user-friendly you can pass the region of the variable into the callback. I.e. not just the raw VarDecl supplied by the marker, but its “run”-time (more like simulation-time) representation as MemRegion, which is basically a combination of a VarDecl and the StackFrameContext of the stack frame in which the instance of the variable you care about has been allocated on the stack. Which is probably always the current stack frame, given that variables don’t generally go out of scope when something happens in completely unrelated code.)

And, yeah, no, you don’t want to look at the liveness information at all. There’s indeed a difference between the liveness of a “run”-time region and the liveness of a syntactic variable, but neither are useful to you. Liveness analysis is mostly used for memory leaks and state cleanup, which are two surprisingly isomorphic problems. But for the purposes of use-after-free, just trust the lifetime marker. That’s your “free” moment.

(The liveness analysis also doesn’t benefit from lifetime markers. It already knows how to mark the variable as dead in the *middle* of the scope, simply by knowing that it’s not referenced anywhere in the code later. And if it’s actually referenced, like in your example, then it probably shouldn’t be marking the variable as dead, as @xazax.hun explained. Like, maybe it still should mark the variable as dead because it cannot be referenced *correctly* later, but that’s not the purpose of liveness analysis, and there’s nothing wrong with some separation of concerns.)

Also if the implementation of the markers is incomplete, I assume that it’s probably incomplete in the sense that some markers are *missing*. Which is perfectly fine for you, you’ll just miss some warnings, this isn’t nearly as bad as having false positives due to having extra markers. And you aren’t trying to “balance” the begin/end markers anyway so it won’t lead to correctness issues. But it may be a good idea to have a Duff’s Device test. You know, just in case.

6

Indeed, for the entire engine, handling graceful lifecycle management is a challenging task. However, for a specific Checker, perhaps implementing some simple functionality can quickly achieve the goal. Just as @NoQ said.
In any case, thank you very much for your reply, which has given me a direction. I will try to research it.

7

Thank you. I helps a lot.
I will try. :grinning_face:

8

Mind that any configuration of CFG::BuildOptions that is not the default in clang, clang-tidy of the clang static analyzer is basically unsupported.
I wouldn’t be surprised if some combination of the options lead to unintended consequences, or even crashes. Don’t be surprised if you step on any of these.
Ideally, of course this wouldn’t be the case, and you could be the one pushing for enabling the Scope markers by default. Once that’s done, it would be in the supported territory.

9

I see. Thanks a lot!

10

FYI, downstream we implement a rule like the one you are working on relying on CFGElement::LifetimeEnds just as @Xazax-hun suggested. I can tell you, they work well enough. Unfortunately, because of the conflict of interest I cannot share the implementation, but I’ll be happy to have a look if you propose something upstream.

11

Great to hear that. I will try to implement it, thank you! :grinning_face:

12

FYI, I got approval to upstream the callbacks for CFGElement::LifetimeEnds. It is nothing complicated, but it is just a piece of the rule that has been proven to work across a few years and Clang versions.

1 Like
13

That looks good!
I found the LifeTimeEnd is very useful for me instead of ScopeEnd when I try to write a checker about use-stack-memory-after-block.

Your code is better and more comprehensive than mine. Through my testing, these Nodes work well in Clang19, but to confirm that they truly work well, perhaps more comprehensive testing is needed.

14

I’m not sure if the reason there were no such callbacks before is that they have some hidden bugs.