Review of the Anatomy of an Assembly
Managed applications minimally consist of one assembly. The .NET Framework also ships with managed code libraries for use with managed code. These libraries are all contained in various, functionally oriented assemblies. You may now wonder what exactly goes into an assembly. Figure 11.1 gives a high-level overview of what assemblies actually contain.
Figure 11.1. The constituents of an assembly.
Let's look a little deeper into each of the constituents of an assembly. MS IL refers to the Microsoft Intermediate Language code contained in an assembly. MS IL, or IL in short, is an object-oriented assembly language that is emitted by compilers targeting the .NET Framework. The IL for each method is Just-In-Time compiled to native code (typically x86 machine code) by the Common Language Runtime as a method is executed. Therefore, IL is not code that can be immediately executed on a given processor, but rather is code that can be quickly compiled at runtime to the native instruction set of the platform on which the Common Language Runtime is hosted.
As will be seen in the section on Verification (“IL Validation and Verification”) later in this chapter, IL code may contain unsafe or dangerous constructs that could undermine Code Access Security. More general, unsafe IL may break type contracts and subvert interassembly isolation. As part of compiling IL to native code, the IL stream is checked for consistency; this process is called IL validation. The process of checking that IL is safe is called IL verification and is an integral part of the Just-In-Time compilation process from IL to native code. Both are required to guarantee the efficacy of the CAS system.
Assemblies also contain metadata. Metadata is a set of tables that describe an assembly's types, their methods, fields, and signatures, as well as the dependencies on other assemblies. You can think of metadata as a rich description of the type definitions and contracts, dependencies, and identity of an assembly—it is an assembly's blueprint. Compilers that target the .NET Framework must not only emit IL but also the metadata describing the compliant they are processing.
Metadata can get intentionally or unintentionally corrupted such as through a malicious user or a disk error. In that case, it would deliver wrong information about the types, fields, or methods contained in an assembly. In fact, IL verification presumes the correctness of assembly metadata. Consequently, metadata needs to be checked before it is used at runtime. The process of doing so is called Metadata validation, and will be covered in more detail later (see “Metadata Validation”).
Resources are an optional ingredient of assemblies. They are not much different from the resources that can be contained in native executables. For example, bitmaps or localization strings could be placed in this section of assemblies. No special set of security checks is required to cover this optional part of assemblies. Indirectly, resource access and use is checked by IL verification passing over the IL code accessing the resource, as well as by metadata checks over the tables containing resource references and definitions.
All managed EXEs and DLLs are emitted by compilers in the PE/COFF (Portable Executable/Common Object File Format). This is a Microsoft-defined file format standard for Windows executable code. Managed PE/COFF files contain information about the location of metadata, entry points, as well as code to start up the CLR. Checks must be made to ensure that none of this information is corrupted. The process of making these checks is called PE file format validation. These checks will be the first set of validation rules we are going to focus on now.