A reader of my books asked me some .NET Questions regarding JIT compiler/strong-naming security. I thought I’d share his questions and my answers with you:
1. According to Microsoft documentation the Just In-Time Compiler takes the following attributes of the machine into account when producing the executable code. Define how these factors alter the output. For example what is meant by CPU Type, what changes to the OS will affect the output.
· The version of the .NET Framework.
[JeffRichter] There may be bugs in the JIT that get fixed in a future release or the CLR may add some features that require that the code be produced differently. For example, in Whidbey, the JIT changes has a different way of calling interface methods than it had in Everett because some internal data structures changed.
· The CPU type (family).
[JeffRichter] The JIT compiler emits code depending on the type of CPU that is in the computer. Obviously code JITted for an x86 CPU will not run on an Itanium (IA64) CPU. But, the JITter can even produce different code for a Pentium 4 versus a Pentium 5.
· The version of the operating system.
[JeffRichter] The JITter may embed the address of some Win32 APIs in to the native code produced. The address of these APIs could change between different service packs of Windows XP (for example)
· The exact identity of the assembly (recompilation changes identity).
[JeffRichter] Obviously, if the assembly changes, the code must be re-compiled.
· The exact identity of all assemblies that the assembly references (recompilation changes identity).
[JeffRichter] The JIT can inline methods contained in one assembly when JIT-compiling a method in another assembly. If the referenced assembly changes, then this may have changed as well and the JITter needs to re-JIT using the new IL code.
· Security factors.
[JeffRichter] The JIT compiler checks security link demands and inheritance demands when JIT compiling to see if it is allowed to JIT compile.
2. What guarantees are there that the JIT compiler will produce the exact same executable every time it is run? How can this be verified?
[JeffRichter] There is no guarantee that this will happen and, in fact, it frequently doesn’t happen. Debug code and release code is completely different, for example.
3. With Strong named components what security testing has Microsoft done to ensure that another assembly can fake itself out to look like another assembly.
[JeffRichter] Strong-named assemblies are hashed and when the CLR loads them, it verifies the hash to ensure that no bits in the assembly have been changed. If a company’s private key is compromised (leaked), then there is no guarantee of security. Microsoft has tested the has algorithms and has modified strong-name assemblies to test they do not load.