C++/CLI C++ Interop and FxCop/Code-Analysis warning CA2122

Question

I've purposely been ignoring a CA2122 warning in some C++ interop code I've been working on for quite some time.  I've just recently had the cycles to investigate the warning  The warning message is as follows

Warning CA2122 : Microsoft.Security : MyClass.Method():Void calls into Marshal.GetExceptionPointers():IntPtr which has a LinkDemand. By making this call, Marshal.GetExceptionPointers():IntPtr is indirectly exposed to user code. Review the following call stack that might expose a way to circumvent security protection:
->System.Runtime.InteropServices.Marshal.GetExceptionPointers : IntPtr
->MyClass.Method : Void
...

MyClass is a managed class where Method calls a native static (for readable illustration purposes only) function; where the code is as follows:

static void MethodImplementation() throw(std::runtime_error &)

{

    //...

    throw std::runtime_error("a message");

    //...

}

 

//...

void MyClass::Method()

{

    try

    {

        return MethodImplementation();

    }

    catch(std::runtime_error &)

    {

        //...

    }

}

My concern isn't that FxCop/Code-Analysis is pumping out this message, it's the LinkDemand that catch(std::runtime_error) is forcing upon this method.

Assume for a moment that the method MethodImplementation is not within my control (cannot modify it) and it can obviously throw an std::runtime_error reference.  While I can add a LinkDemand attribute to the Method method, strong-name its assembly, and either throw that assenbly in the GAC or manually give it FullTrust and the implications of this LinkDemand go away; but I don't think I should need to.  There's are some architectural and policy issues to simply going FullTrust to swallow the "inherited" security demands of the Method method (like APTC); but this should all be an implementation detail, and the abstraction of C++ interop has leaked through to my implementation.

Any thoughts?

Answer 1

Peter, is that still an open issue?

Thanks,

Ayman Shoukry

VC++ Team

Answer 2

Hi Ayman. Last I heard, the Code Analysis team is still discussing this.

Answer 3

Thanks Peter!

Just keep us updated once you have more details. If you need help from the my side (VC++ team), let me know.

Thanks,

Ayman Shoukry

VC++ Team

Answer 4

Bump to top.

Answer 5

Brian Kramer wrote:

Bump to top.

Hi Brian.  Are you looking for a resolution to this issue?  I've sort of relegated it to my "suppressible" list due to it's cross-team context.  I don't expect to see any new changes/fixes until well after Orcas.

Answer 6

Hey Peter.  I'm just maintaining its visibility.  Looks like this is one of those threads that can't get resolved.

Answer 7

Ayman is pretty good at keeping track of these things; but, there hasn't been a decision made on it that I've been made aware of (otherwise I would have added a comment of some sort).  I feel like it's a couple of issues myself.  The more important issue is that the C/C++ compiler is generating code that requires a LinkDemand even though it's within an UnmanagedCode permission context.  Getting rid of that (by pushing the LinkDemand into a system DLL and wrapping it with an assert) would get around the warning.  The other issue is the warning, some feel the warning about a call to a method with a LinkDemand for UnmanagedCode shouldn't be raised when the assembly has a SecurityPermission attribute for UnmanagedCode.  In this case the assembly has [assembly:SecurityPermission(SecurityAction::RequestMinimum, UnmanagedCode = true)] and there is still a warning that GetExceptionPointers has a LinkDemand for UnmanagedCode...  I've sent a fresh ping about the issue and I'll post any pertinent (disclosable) information.

Answer 8

Hi Peter,

Hopefully, you already got some feedback. Please unmark the previous post if the issue is still open or you can just add any updates an then unmark the thread.

Thanks,

Ayman Shoukry

VC++ Team