In the last post, I have covered an aspect of sandboxing – unexpected AppDomain switches caused by thread promotion. In this post, I will focus on sandboxing, too. However, this time the primary focus is not security but performance. Nevertheless, at the end of this post, I will present an idea that might cause you less pain if you think about the thread-promotion issue.

So what are the performance issues of executing plug-ins in sandboxed AppDomains? Creating and managing AppDomains internally is by far not the most expensive part here. Typically, calls across application domains have much more impact on performance. There are different options for calling across application domains:

• AppDomain.DoCallback
• Calling objects in other application domains via transparent proxies
• ICLRRuntimeHost::ExecuteInAppDomain (a COM-based API internally used by msclr/appdomain.h and its various call_in_appdomain templates)

Compared to calls inside an appdomain, all of these options are dark slow. Even if you use an optimization described here, there is a significant cost involved in cross AppDomain calls. For scenarios that require a lot of calls between the host application and the plug-in and vice versa, this is often not acceptable.

A customer of mine recently came up with a simple but very interesting idea that I have not considered so far: Why should the plug-in be executed in a different AppDomain? Can’t we create a sandboxed AppDomain in which only our assemblies and system assemblies have full-trust permissions whereas the plug-ins can only use a restricted permission-set?

Like most interesting questions, this question is not easy to answer. I do not claim that I have the ultimate answer to this question, but I want to explain my opinion here. At the end of the day it comes down to the question what are the real benefits an AppDomain can give you? In a later post, I will likely address AppDomains in more detail. For now it is sufficient to know that AppDomains can provide isolation; they are boundaries especially for

• assembly and type loading (and unloading)
• configuration
• CAS security assignments

The first use-case for AppDoamins was ASP.NET. I think it is in fact fair to say, that many features of AppDomains only exist because the ASP.NET team needed them. However, this does not mean that these features are needed in all plug-in scenarios. Let’s take a look at each item mentioned above:

Assembly and type loading (and unloading): If you need hot-pluggable plug-ins (those that can be plugged in and out at runtime) you have to use AppDomains. AppDomains offer shadow copying of loaded assemblies which allows you to overwrite the assembly while it is loaded and, as explained here, shutting down AppDomains is the only way to unload assemblies. However, for many pluggable applications, it is acceptable that a restart of the application is required to replace a plug-in.

Configuration: While it can be convenient if each plug-in can have its own configuration file, it is seldom a strict requirement. For many applications, it is acceptable if the app and the plug-ins have to share a configuration file. In my experience, a plug-in typically receives its configuration as creation-parameters from the host application and not via configuration files.

CAS permission assignments: For this aspect the answer is not that easy. Is it more secure if a plug-in is executed in a separate sandboxed application domain? Isn’t it sufficient if the host and the plug-in are executed in a sandboxed application domain in which the host’s code has full-trust permissions and the plug-in is executed with restricted permissions? Are there aspects that make it easier for a sandboxed plug-in assembly to exploit assemblies in its own application domain than to exploit assemblies in other application domains? I am not aware of such a case, but I do not dare to say “no” here. Maybe there is a CAS permission that I have not thought of, and maybe you can use it in a way that I have not considered yet. If such a permission exists and if this permission is granted to the sandboxed plug-in, it could bypass CAS. However, if your sandbox has only the permission to execute type-safe code (SecurityPermissionFlag.Execute) and if everything else the plug-in needs is provided by an types that the host application provides to the plug-in developer, the plug-in would not have such a permission. Therefore my personal answer to this question is: For a plug-in that has only the execution permission, I consider it safe to have the application and the plug-in executing in the same sandboxed application domain. If you disagree with me, I would be more than happy if you could tell me your opinion (my email address alias is my firstname the server name is heege.net).

If you agree with me, it is time to discuss how to create a sandboxed application domain. One option is to use the simple sandboxing API, however, there are two disadvantages in this case:

• You would have to name each and every non-GACed assembly that should have full-trust permissions. For realistic applications this list could be quite long.
• As discussed here, it is easy to write code that causes unintended switches to the (full-trusted) default application domain

Key to solving the latter issue is sandboxing the default application domain: If the default application domain is sandboxed, so that a plug-in executes only with the permission to execute type-safe code, and if the plug-in as well as the host application execute in the same application domain, there is no need to create another application domain and thread-promotion automatically ends up in the right application domain.

Sandboxing the default application domain requires a custom AppDomainManager implementation. In this implementation you can to specify a HostSecurityManager. This HostSecurityManager could then grant full-trust permissions to all assemblies with your public key and execution-only permissions to all other assemblies. (Notice that assemblies from the GAC are always full-trust assemblies). The following C# code shows how to implement and AppDomainsManager:

// AppDomainSandboxer.cs
// compile with: csc /t:library /keyfile:keyfile.snk AppDomainSandboxer.cs

using System;
using System.Reflection;
using System.Security;
using System.Security.Policy;
using System.Security.Permissions;

namespace AppDomainSandboxer
{
  public classSandboxingAppDomainManager : AppDomainManager
  {
    SandboxingHostSecurityManager hostSecurityManager =
             newSandboxingHostSecurityManager();

    publicoverrideHostSecurityManager HostSecurityManager
    {
      get
      {
        return hostSecurityManager;
      }
    }
  }

  public classSandboxingHostSecurityManager : HostSecurityManager
  {
    private staticPermissionSet psExecute;

    private staticPermissionSet psFullTrust;

    private staticStrongNamePublicKeyBlob publicKeyBlob;

    static SandboxingHostSecurityManager()
    {
      psExecute = newPermissionSet( PermissionState.None);
      psExecute.AddPermission( newSecurityPermission(
                                     SecurityPermissionFlag.Execution));
      psFullTrust = newPermissionSet( PermissionState.Unrestricted);
      foreach ( object evObj inAssembly.GetExecutingAssembly().Evidence)
      {
        StrongName sn = evObj asStrongName;
        if (sn != null)
        {
          publicKeyBlob = sn.PublicKey;
          return;
        }
      }
      thrownewException( "No public key found in AppDomainSandboxer assembly");
    }

    public overrideHostSecurityManagerOptions Flags
    {
      get
      {
        returnHostSecurityManagerOptions.HostResolvePolicy;
      }
    }

    public overridePermissionSet ResolvePolicy( Evidence evidence)
    {
      foreach ( object evObj in evidence)
      {
        StrongName sn = evObj asStrongName;
        if (sn != null)
        {
          if (sn.PublicKey.Equals(publicKeyBlob))
          {
            return psFullTrust;
          }
          return psExecute;
        }
      }
      return psExecute;
    }
  }
}

There are two options to use this SandboxingAppDomainManager inside an application: You can either start the application with two special environment variables named APPDOMAIN_MANAGER_ASM and APPDOMAIN_MANAGER_TYPE as described here, or you can create a native application that hosts the CLR.

1) Since April, 1st I am an MVP for Visual C++.

2) My first article in the MSDN Magazine has been published: http://msdn.microsoft.com/msdnmag/issues/06/05/MixAndMatch/default.aspx

In news://msnews.microsoft.com/microsoft.public.dotnet.languages.vc Edward Diener asked an very interesting question: Why can't I call a function having arguments of a native type like std::string from another assembly?

http://www.mybadhairday.com/cppcliinstall.html

When a cpp file is compiled with /clr, a managed object file is created. In most scenarios, such a managed object file contains only managed code. However, there are two scenarios that end up in a managed object file with managed and native code:

1. When #pragma unmanaged is used
2. When the C++ file contains a function with C++ constructs that are not mappable to IL code.

Managed object files with native code imply a certain danger: They can end up in uninitialized state, as shown in the following sample:

In the code below, i is a global variable initialized with the return value of getValue(). There are two exported functions that simply return i. One is the managed function fManaged and the other one is the unmanaged function fUnmanaged.

<code language=”C++/CLI” filename=”MixedLib.cpp” compileWith=”CL /LD /clr MixedLib.cpp”>
#pragma unmanaged
__declspec(noinline) int getValue() {
  return 42;
}

int i = getValue();

__declspec(dllexport) int fUnmanaged()
{
  return i;
}

#pragma managed
__declspec(dllexport) int fManaged()
{
  return i;
}
</code>

Before fManaged is executed the first time, the module constructor is called. The module constructor calls getValue to initialize the global variable i. However, if fUnmanaged is called before fManaged is called the first time, the variable i will be returned before it is initialized. To reproduce this scenario, you can use the client application below.

<code language=”C++/CLI” filename=”TestApp.cpp” compileWith=”CL /clr TestApp.cpp”>
#include <stdio.h>

#pragma comment(lib, "testlib.lib")

__declspec(dllimport) int fUnmanaged();
__declspec(dllimport) int fManaged();

int main()
{
  printf("fUnmanaged returns %d\n", fUnmanaged());
  printf("fManaged returns %d\n", fManaged());
  printf("fUnmanaged returns %d\n", fUnmanaged());
}
</code>

If you start TestApp.exe, you will get the following output:

fUnmanaged returns 0
fManaged returns 42
fUnmanaged returns 42

The easiest way to avoid these problems is to make sure that files compiled with /clr contain only managed code and to leave the native code in cpp files compiled without /clr. If you consider using #pragma unmanaged or unmappable C++ constructs in files compiled with /clr, you should be aware that all global variables and static member variables of that file, are initialized by the module initializer. This is even true if the variable is of a native type.

The compiler's ability to automatically compile a function with unmappable C++ constructs to native code can cause a scenario where you get mixed code object files without even realizing it. Fortunately a compiler warning C4793 can be emitted in this scenario. C4793 is a level 2 warning. To get it, you either have to set the warning level to 2, or you have to use a compiler switch to make it a level 1 warning, as shown in the following code.

<code language="C++/CLI"
     filename=" UnmappableConstructs.cpp"
     compileWith="cl /c /clr /w14793 UnmappableConstructs.cpp">
void f()
{
  __asm int 3;
}
</code>

When you compile this code, the C++ compiler will emit the warning C4793 with the following message:

UnmappableConstructs.cpp(3) : warning C4793: '__asm' : causes native code generation for function 'void f(void)'
        UnmappableConstructs.cpp(1) : see declaration of 'f'

On microsoft.public.dotnet.languages.vc, bonk has asked this interesting question. This blog entry gives you a simple example and explains why this is possible. In further blogs I will discuss when this can be dangerous.

Your idea is possible, but there may be some issues. Let's start with a simple sample

<code language="CPPCLI" file="test.cpp" compileWith="CL /LD /clr test.cpp">
// pragma managed is the default
extern "C" __declspec(dllexport) void __stdcall f()
{
  System::Console::WriteLine("I am f(), a managed function that test.dll exports to native clients");
}
</code>

"dumpbin /exports test.dll" will show you that there is indeed a native exported function:

    ordinal hint RVA      name

          1    0 00001020 _f@0

What is going on here? How can unmanaged code can call managed code?

To answer this question, let's have a look at a simple application that calls managed code from unmanaged code:

<code language="CPPCLI" file="testApp.cpp" compileWith="CL /clr testapp.cpp">
void f()
{
  System::Console::WriteLine("I am f(), a managed function that can be called by native clients");
}

void f2()
{
  System::Console::WriteLine("I am f2(), a managed function that can be called by native clients");
}

#pragma unmanaged
int main() {
  f();
  f2();
}
</code>

The native function main can not call f  without some magic that is going on under the hood: Think of a scenario, where f has not even been jit compiled. On the one hand, the call "f()" is compiled to a call to an address local to the exe file, on the other hand, the code that should really be executed, is JIT compiled. So what is going on here?

"f()" and "f2()" are indeed calls a local addresses. This is an excerpt from the disassembly window:

  f();
00401053  call        f (401030h)
  f2();
00401058  call        f2 (401040h)

Notice that the calling addresses (00401053) and the called addresses (401030) are both belong to testApp.exe's code.

Here is what the disassembly window tells us about the called addresses:

f:
00401030  jmp         dword ptr [__mep@?f@@$$FYAXXZ (409000h)]

f2:
00401040  jmp         dword ptr [__mep@?f2@@$$FYAXXZ (409004h)]

"jmp dword ptr [...x...]" is an indirect jump. It means: at the address ...x..., is the address the address you have to jump to.

Here is what these addresses are in my debugger's memory window:
0x00409000:  00 CB 00 12
0x00409004:  00 CB 00 4E

Both addresses are far away from testApp.exe's base address, so they are clearly outside testApp's code. This is runtime generated code, but we have not yet reached JIT compiled code. What we see here are runtime generated unmanaged -> managed thunks. These thunks perform the managed / unmanaged transition call the managed functions (f, or f2) in the end.

As I have mentioned, these functions are runtime generated: How does the runtime know that at address 0x00409000 should be a pointer to the unmanaged -> managed thunk for f() and at address 0x00409004 should be a pointer to the thunk for f2()?

Well the new linker is much smarter than you may expect: The linker generates .NET metadata that tells the runtime exactly that! If you view testApp.exe in ILDASM and inspect the assembly's manifest, you will find so called vtFixups at the end of the manifest. Here is an expert:

.imagebase 0x00400000
.subsystem 0x0003       // WINDOWS_CUI
.corflags 0x00000000
.vtfixup [1] int32 retainappdomain at D_00009000 // 06000001
.vtfixup [1] int32 retainappdomain at D_00009004 // 06000002
...many other vtfixups elided for clarity here ...

Note that these lines contain familiar numbers: 00009000 and 00009004. If you add the .imagebase to these numbers, you will get:

00409000 and 00409004. Does this ring the bell? Using these addresses, the compiled code finds the managed -> unmanaged thunks.

So what is the other part of the vtfixup 06000001 and 06000002?

Well these are metadata tokens. Metadata starting with the 06 are always method tokens and now it is not very difficult to guess what is going on: 06000001 is the metadata token for the managed function f() and 06000002 is the metatdata token for f2(). You can prove this by adding the following code to f() and f2():

System::Console::WriteLine("{0:x8}", (gcnew System::Diagnostics::StackTrace())->GetFrame(0)->GetMethod()->MetadataToken);

The .vtfixup metadata tells the runtime:
When the assembly is loaded:
  Generate a unmanaged->managed thunk for the method f() and store a pointer to it in 00409000 and
  generate another unmanaged->managed thunk for method f2() and store a pointer to it in 00409004.

Since this is done, the unmanaged function main can call the managed functions f and f2 as if they were native functions.

In the testApp.exe sample there is a simplification, that is not true for the test.dll I have disused right at the beginning: Since testApp.exe is an exe it is guaranteed that the CLR has been initialized already. (The CLR will be initialized automatically when the EXE application starts.) This assumption is not true for managed functions exported via DLLs: The DLL's client may be a native client. To handle this case, a small stub is exported. This small stub ensures that the CLR is initialized properly and that the assembly is loaded properly into the default appdomain, before the unmanaged -> managed stub is called. This is often called delayed CLR initialization.

Although all this sounds nice there are still some things to discuss:

* Issues when combining exported managed functions with #pragma managed

* Turning the generation of managed / unmanaged thunks off in cases where they are not needed

* What happens if managed code calls a managed entry point via P/Invoke?

I hope I will find some time to discuss these things in the next days.