关于Ngen(pre-JIT)安全性的讨论

有人问到Assembly经过Ngen之后会不会影响CLR的安全性的保证。比如说让CAS(Code Access Security)无法正常或充分的工作。

简单的回答是：不需要有这样的担心。

更长的回答如下：
Your assembly has to be compiled to run. NGEN just pre-compiles your assembly so at runtime your assembly does not have to be re-compiled. It does not bypass security. It does not lose verifiability.

So, from a usage perspective pre-jitted (ngened) assemblies and non-prejitted assemblies are both subject to at-runtime Code Access Security restrictions and running a pre-jitted assembly will not subvert CAS policy settings.

The reason why you may have read about “security differences” likely has to do with the implementation choices we took to actually ensure pre-jitted assemblies will run safely: At ngen time the security permissions that local CAS policy determines for the assembly that is to pre-jitted are injected into the pre-jitted image as security context information that the CLR will later look at to determine whether the pre-jitted code can actually run or not. If at runtime of a pre-jitted assembly the security context for that assembly turns out to be more restrictive than what has been recorded in the pre-jitted image, the CLR will revert to the non-pre-jitted code, and do JIT compilation of IL of the assembly as if there is no pre-jitted version around.

This essentially means, that at worst you might see a very slight perf start up hit and lose perf optimizations gained by pre-jitting if the pre-jitted assembly is attempted to run in a tighter security context than the one in which it had been ngened. 

The same goes for verification. The assembly to be pre-jitted is verified. If it turns out to be unverifiable then a request to be granted the skip verification permission is included in the security context of the pre-jitted assembly, meaning that the pre-jitted native bits will only run in that case if at runtime the CAS security policy grants that assembly the right be unverifiable.