C++: Model Microsoft's "Active Template Library"

[MathiasVP]

This PR adds MaD models for most of the relevant classes in Active Template Library (ATL).

In addition I've also added ATL flow sources whenever I came across something relevant.

There are still some models that could do with more MaD rows, but they depend on a couple of features that aren't yet available. In particular:

• It's not currently possible to add a MaD row for a templated conversion operator. i.e.:

    template<typename T>
    struct MyStruct {
        operator T();
    };

  because the name of the conversion operator is just whatever name T is instantiated with. You can see an example of where this is used here (where you'd like taint from this to the result of the call). A natural way to write this MaD would be:

  ["", "CAtlFileMapping<T>", True, "operator T *", "", "", "Argument[-1]", "ReturnValue[*]", "taint", "manual"]

  However, we don't currently allow using template arguments in the "name" column like we do for the signature column. I plan on tackling this as a follow-up to this PR.
• Lots of container related models contains code allows you to do stuff like:

  Container container;
  POS pos = container.find(myValue);
  sink(container.lookup(pos));

  we could add a taint-step from find to the return value, and a taint-step from lookup's argument to its return value, in order to get this taint. However, I would much rather do the very small addition to dataflow (that Java has) which adds a MapKey content to express that "this is a key that points to something tainted". So that's another follow-up from this PR.

In addition to adding a bunch of models, this PR also fixes two problems in our interpretation of MaD rows:

• It was impossible to add non-templated models since we were using isConstructedFrom in a few places to obtain the uninstantiated template of classes and functions. The problem with that is that isConstructedFrom doesn't have a result when the function/class isn't a template instantiation. So I fixed that as part of this work, and you can see the effect of this in the commit that follows the fix.
• As I mentioned offline, a conversion operator such as:

    using MyInt = int;
    struct S {
      operator MyInt();
    };

  gets the name operator int instead of operator MyInt. So without some special handling a MaD row for operator MyInt would have to use the name operator int which is slightly confusing. So I added special handling of conversion operators so that we get the name operator MyInt instead. The effect of this can also be seen in the commit that follows the fix.

Commit-by-commit review highly encouraged. There is a lot of code, but most of it is just adding tests and models. Every commit can be read and understood in isolation!

[MathiasVP]

I've responded to all the comments now, Geoffrey. While fixing some of them I also spotted a bug in one of the models that I fixed in 279a30c

[geoffw0]

Another 8 commits reviewed (to the end of CPathT).

[geoffw0]

What's going on here? I mean, what is .Field[*m_psa].Field[*@pvData] and why do we sometimes reference it instead of just .Field[*m_psa]?

[MathiasVP]

The m_psa field is a public member of CComSafeArray: https://learn.microsoft.com/en-us/cpp/atl/reference/ccomsafearray-class?view=msvc-170#m_psa. So it's possible to do:

CComSafeArray<int> array;
array.Add(42);
LPSAFEARRAY underlyingArray = array.m_psa;
int* data = (int*)underlyingArray->pvData;
printf("%d", *data); // this will print 42

So in order to capture this flow we model the effect of calling Add by making it a write to the m_psa->pvData member.

[MathiasVP]

Wonderful 🦅 eye'ing, Geoffrey! I've responded to all of them now.

[geoffw0]

Review complete. 😅 🎉

Overall this looks fantastic, I expect it will really improve flow (and sources for that matter) in projects that use this stuff heavily.

[geoffw0]

I feel like there are potentially some queries we could develop or extend into the area of memory mapped files.

[geoffw0]

I feel we should also model CRegKey::Create, which I believe is commonly used when adding new data structures in the registry. The lpszKeyName (Argument[*1]) should have taint flow into the qualifier.

(it could also be a query sink, you would not want untrusted data controlling this operation)

[MathiasVP]

Agreed. I've added this summary model in 674dbce. I think this is one that could also be treated with MapKey flow at some point and be made value-preserving.

[geoffw0]

I don't think it will be value preserving as you're still appending the key name to an existing registry path represented by the current state of the key. Unless maybe you consider the key to be a set of path edges, in which case I suppose you're adding one value.

[MathiasVP]

Unless maybe you consider the key to be a set of path edges, in which case I suppose you're adding one value.

Yeah, that was my thinking. But I guess we can settle on those details later. I agree that there are multiple ways to think of this.

[MathiasVP]

I believe I've addressed everything @geoffw0. The only discussion point left is #18136 (comment).

[geoffw0]

All of my concerns have been addressed, I think we're ready to merge. ✨