Верификация CIL-кода. Библиотеки для создания метаинструментов

Особенности верификатора кода, используемого в .NET

Верификатор кода .NET относится ко второму типу. Он может доказать, что сборки, генерируемые компиляторами C#, J# и Visual Basic .NET, не разрушают память. При этом он терминируем и имеет линейную сложность.

Здесь может возникнуть следующий вопрос: зачем нужен верификатор, если компиляторы и так генерируют не разрушающий память код? Чтобы ответить на этот вопрос, нужно вспомнить, что:

Другими словами, верификатор .NET предназначен не для поиска ошибок в программах, а для обеспечения безопасности системы.

Мы будем различать два достаточно близких понятия, относящихся к верификации. Это верифицированный код и верифицируемый код.

Верифицируемый код - это код, для которого верификатор может доказать, что он не разрушает память. Другими словами, для верифицируемого кода можно заранее, еще до запуска верификатора, сказать, что он успешно пройдет верификацию (такой код может генерироваться компилятором C#).

Верифицированный код - это код, для которого верификатор доказал, что он не разрушает память. То есть чтобы из верифицируемого кода получить верифицированный код, нужно обязательно запустить верификатор.

Алгоритм верификации

В спецификации CLI предложен базовый вариант алгоритма верификации. Любая реализация CLI должна включать верификатор, верифицирующий по крайней мере те программы, которые допускает базовый алгоритм.

Алгоритм верификации представляет собой вариант абстрактного интерпретатора CIL-кода. Линейность алгоритма верификации достигается за счет того, что он просматривает тело метода последовательно инструкция за инструкцией (при этом ни одна инструкция не обрабатывается дважды).

Совместимость типов

Пусть S и T - типы. Тогда S[] и T[] - соответствующие им массивные типы, а S и T - типы соответствующих управляемых указателей.

Тот факт, что S совместим по присваиванию с T, мы будем записывать как S := T.

Операция := рефлексивна и транзитивна.

Правила совместимости типов:

Если ни одно из этих правил не выполняется, то типы S и T несовместимы.

Конфигурации стека

Будем называть конфигурацией стека данные о количестве слотов на стеке и типы значений, лежащих в этих слотах. При этом конфигурацию, содержащую 0 слотов, будем называть пустой конфигурацией.

Рассмотрим две операции над конфигурациями, которые используются в алгоритме верификации:

Операция проверки совместимости имеет два операнда: конфигурации C и K. Она возвращает булевское значение, показывающее, совместима ли конфигурация C с конфигурацией K.

Приведем алгоритм вычисления операции проверки совместимости:

Операция слияния двух конфигураций также имеет два операнда: конфигурации C и K. Она может либо закончиться неуспехом, либо возвращает конфигурацию R, вычисляемую по следующему алгоритму:

Описание алгоритма

В процессе работы алгоритма для каждой инструкции CIL вычисляется конфигурация стека. При этом фактические значения, лежащие на стеке, в локальных переменных и параметрах метода, не учитываются.

Алгоритм верификации работает со следующими данными:

Возможны два результата работы алгоритма:

В начале работы алгоритма в массиве M не записано ни одной конфигурации.

Алгоритм последовательно просматривает массив P, то есть на каждом шаге работает с одной инструкцией P[i], где i пробегает значения от 1 до N (будем считать, что массивы P и M нумеруются, начиная с единицы).

На каждом шаге алгоритма выполняются следующие действия:

Если все инструкции были просмотрены и ни на одном шаге алгоритм не завершился неуспехом, то метод успешно прошел верификацию.

Библиотеки для создания метаинструментов

Во второй главе мы рассмотрели написанную на языке C программу, осуществлявшую генерацию сборки .NET. Эта программа не использовала никаких библиотек для работы с метаданными и CIL-кодом, то есть задача генерации сборки была решена на самом низком уровне - на уровне двоичных форматов. Хотя такой подход во многих случаях бывает оправдан, на практике гораздо удобнее воспользоваться специальными библиотеками, предназначенными для разработчиков метаинструментов.

Напомним, что метаинструменты для платформы .NET - это программы, рассматривающие сборки .NET в качестве объектов анализа, генерации или преобразования. При этом анализ существующей сборки выполняется верификаторами, загрузчиками, отладчиками и т.д. Генерация новой сборки осуществляется компиляторами и RAD-средствами. Преобразование сборки выполняется оптимизаторами и средствами, затрудняющими декомпиляцию и взлом сборки.

Сборка .NET представляет собой совокупность метаданных, CIL-кода и, возможно, ресурсов. Поэтому библиотеки, необходимые для создания метаинструментов, должны обеспечивать чтение и генерацию этой информации. В составе .NET Framework SDK поставляются две библиотеки, частично решающие эти задачи. Это Metadata Unmanaged API и библиотека рефлексии (Reflection API). Кроме того, существуют созданные сторонними разработчиками библиотеки AbsIL SDK и Reflection Extension API. В данном разделе проведем обзор этих библиотек.

Metadata Unmanaged API

Metadata Unmanaged API осуществляет импорт и генерацию метаданных. Это API, как явствует из его названия, работает не под управлением .NET Runtime. Оно предназначено, главным образом, для использования в компиляторах и загрузчиках, которым требуется высокая скорость доступа к метаданным и работа с метаданными на низком уровне.

При использовании Metadata Unmanaged API метаинструмент работает с образом сборки в памяти (в документации такой образ называется scope). Метаинструмент может создать образ новой сборки или загрузить существующую сборку из файла, а кроме того, может сохранить образ сборки в файл. Навигация через иерархию метаданных осуществляется на достаточно низком уровне с использованием токенов метаданных (напомним, что токен некоторого элемента метаданных - это 32-разрядное число, старший байт которого обозначает таблицу, в которой хранятся элементы метаданных соответствующего типа, а остальные три байта являются индексом элемента в этой таблице). Metadata Unmanaged API предоставляет прямой доступ к таблицам метаданных, позволяет сливать несколько сборок в одну, но не содержит явных средств для работы с CIL-кодом. Кроме того, метаинструмент, использующий это API, должен быть написан на C++.

Для того чтобы использовать Metadata Unmanaged API из программы, написанной на Visual C++, необходимо включить в программу следующие строки:

#include <corhlpr.h>
#pragma comment(lib, "format.lib")

Первая строка подключает заголовочный файл, в котором описываются нужные интерфейсы, а также вспомогательные структуры данных и функции. Вторая строка дает указание компоновщику использовать библиотеку format.lib.

Взаимодействие с Metadata Unmanaged API осуществляется через набор COM-интерфейсов. Они перечислены в таблице 4.2.

Работа с Metadata Unmanaged API начинается с инициализации системы COM и получения указателя на интерфейс IMetadataDispenserEx:

CoInitialize(NULL);
IMetaDataDispenser *dispenser;
HRESULT h = CoCreateInstance(
 CLSID_CorMetaDataDispenser,
 NULL,
 CLSCTX_INPROC_SERVER, 
 IID_IMetaDataDispenserEx,
 (void **)dispenser
 );
if (h)
 printf("Error");

Затем можно с помощью метода OpenScope этого интерфейса загрузить существующую сборку в память или с помощью метода DefineScope создать новую сборку. Оба метода возвращают указатель на интерфейс, через который можно в дальнейшем осуществлять чтение или генерацию метаданных. В следующем фрагменте программы происходит вызов метода OpenScope для чтения метаданных из сборки test.exe:

IMetaDataImport *mdimp;
HRESULT h = dispenser->OpenScope(
 L"test.exe",
 0,
 IID_IMetaDataImport,
 (IUnknown**)mdimp
 );
if (h)
 printf("Error");

При завершении работы с Metadata Unmanaged API необходимо освободить указатели на полученные интерфейсы:

mdimp->Release();
dispenser->Release();

Чтение метаданных из сборки осуществляется через методы интерфейса IMetadataImport, которые условно можно разделить на три основные группы:

mdTypeDef tmp;
mdTypeDef *tokens;
HCORENUM Enum = 0;
unsigned long tokenCount;
mdimp->EnumTypeDefs(Enum,tmp,1,tokenCount);
mdimp->CountEnum(Enum,tokenCount);
if (tokenCount > 0)
{
  tokens = new mdTypeDef [tokenCount];
  tokens[0] = tmp;
  if (tokenCount > 1)
	mdimp->EnumTypeDefs(
	Enum,tokens+1,tokenCount-1,
	tokenCount
	);
  mdimp->CloseEnum(Enum);
}

mdTypeDef token;
mdimp->FindTypeByName(L"MyType1",NULL,token);

unsigned short s[1024];
unsigned long len;
mdimp->GetUserString(strToken,s,1024,len);

Генерация метаданных осуществляется через методы интерфейса IMetadataEmit, которые можно условно разделить на две группы:

Сгенерированные метаданные могут быть сохранены на диске при помощи метода Save.

Reflection API

Библиотека рефлексии содержит классы для работы с метаданными на высоком уровне (эти классы располагаются в пространствах имен System.Reflection и System.Reflection.Emit ). Она соответствует спецификации CLS, поэтому использующий ее метаинструмент может быть написан на любом языке платформы .NET, который является потребителем CLS-библиотек.

Чтение метаданных через рефлексию

Метаинструмент, использующий библиотеку рефлексии, получает доступ к метаданным сборки через экземпляр класса Assembly, который создается при загрузке сборки в память. Затем через методы класса Assembly можно получить объекты класса Module, которые соответствуют модулям, входящим в сборку. Класс Module, в свою очередь, позволяет получить набор экземпляров класса Type для входящих в модуль типов, а уже через эти объекты можно добраться до конструкторов (класс ConstructorInfo ), методов (класс MethodInfo ) и полей (класс FieldInfo ) типов. То есть библиотека рефлексии спроектирована таким образом, что создание объектов рефлексии, соответствующих элементам метаданных, осуществляется путем вызова методов других объектов рефлексии (схема получения доступа к объектам рефлексии показана на рис. 4.5, при этом сплошные стрелки обозначают основные пути получения доступа, а пунктирные - дополнительные пути). Другими словами, конструкторы классов, входящих в библиотеку, для пользователя библиотеки недоступны. Информацию о любом элементе метаданных можно прочитать из свойств соответствующего ему объекта рефлексии.

Экземпляр класса Assembly, с создания которого, как правило, начинается работа со сборкой через рефлексию, можно получить разными способами:

Assembly assembly = Assembly.GetExecutingAssembly()

Assembly assembly = Assembly.GetAssembly(typeof(int))

Assembly assembly = Assembly.LoadFrom("test.exe")

Сборка .NET, как правило, состоит из одного модуля, хотя существует возможность включения в сборку сразу нескольких модулей. Получение доступа к объектам класса Module, описывающим модули, из которых состоит сборка, осуществляется одним из двух способов:

Module module = assembly.GetModule("SomeModule.exe")

Module[] modules = assembly.GetModules(false)

Через объект класса Module мы можем обратиться к глобальным полям и функциям модуля (глобальные поля и функции не принадлежат ни одному классу), используя методы GetField и GetFields для полей, а также GetMethod и GetMethods для функций. При этом полям будут соответствовать объекты класса FieldInfo, а методам - объекты класса MethodInfo. В следующем примере мы выводим на экран сигнатуры всех глобальных функций некоторой сборки "test.exe":

Assembly assembly = Assembly.LoadFrom("test.exe");
Module[] modules = assembly.GetModules(false);
foreach (Module mod in modules)
{
  MethodInfo[] methods = mod.GetMethods();
  foreach (MethodInfo met in methods)
    Console.WriteLine(met);
}

Особое место в библиотеке рефлексии занимает класс Type, представляющий типы. Область применения этого класса значительно шире, чем области применения остальных классов рефлексии, и этот факт отражен в том обстоятельстве, что класс Type входит в пространство имен System, а не System.Reflection.

В каждом классе существует унаследованный от класса System.Object метод GetType, возвращающий экземпляр класса Type, который описывает этот класс. В следующем примере метод GetType будет использован для динамического определения типа объекта o (так как этот объект представляет собой строку, то на печать будет выведено сообщение "Sytem.String"):

object o = new String("qwerty");
Type t = o.GetType();
Console.WriteLine(t);

В C# определен специальный оператор typeof, который возвращает объект класса Type. Например, если нам нужно получить объект Type, представляющий тип массива строк, мы можем записать:

Type t = typeof(string[]);

Кроме этого, доступ к информации о типе можно получить, зная имя этого типа:

Type t = Type.GetType("System.Char");

Мы также можем воспользоваться методами GetTypes классов Assembly и Module для получения массива типов, объявленных в сборке или модуле. В следующем примере на экран выводится список типов, содержащихся в сборке "test.exe":

Assembly assembly = Assembly.LoadFrom("test.exe");
Type[] types = assembly.GetTypes();
foreach (Type t in types)
  Console.WriteLine(t);

Имея объект рефлексии, соответствующий некоторому типу, мы имеем возможность получить доступ к объектам рефлексии, описывающим его поля, конструкторы, методы, свойства и вложенные типы. При этом, если мы знаем их имена, мы можем воспользоваться методами GetField, GetConstructor, GetMethod, GetProperty и GetNestedType класса Type. А если мы хотим получить массивы объектов рефлексии, описывающих члены типа, то нам нужно вызвать методы GetFields, GetConstructors, GetMethods, GetProperties и GetNestedTypes. В следующем примере на экран выводится список типов, содержащихся в сборке, вместе с сигнатурами их методов:

Assembly assembly = Assembly.LoadFrom("test.exe");
Type[] types = assembly.GetTypes();
foreach (Type t in types)
{
  Console.WriteLine(""+t+":");
  MethodInfo[] methods = t.GetMethods();
  foreach (MethodInfo m in methods)
    Console.WriteLine("  "+m);
}

Для каждого метода и конструктора мы можем получить доступ к массиву объектов рефлексии, описывающих его параметры. Для этого служит метод GetParameters, объявленный в классах MethodInfo и ConstructorInfo. Данный метод возвращает массив объектов класса ParameterInfo:

ParameterInfo[] parms = method.GetParameters();

Управление объектами

Кроме чтения метаданных, библиотека рефлексии позволяет создавать экземпляры типов, входящих в обрабатываемую сборку, вызывать методы этих типов, читать и изменять значения полей.

Рассмотрим класс TestClass:

class TestClass
{
  private int val;
  public TestClass() { val = 7; }
  protected void print() { Console.WriteLine(val); }
}

В следующем примере мы используем метод Invoke класса MethodInfo для вызова метода print объекта класса TestClass. Обратите внимание, что метод print объявлен с модификатором доступа protected.

static void CallMethodDemo()
{
  TestClass a = new TestClass();
  BindingFlags flags = (BindingFlags)
   (BindingFlags.NonPublic | BindingFlags.Instance);
  MethodInfo printer =
    typeof(TestClass).GetMethod("print",flags);
  printer.Invoke(a, null);
}

Путем внесения небольших изменений в CallMethodDemo мы можем добиться того, что объект класса TestClass будет также создаваться через рефлексию (с помощью вызова его конструктора):

static void CallMethodDemo2()
{
  Type t = typeof(TestClass);
  BindingFlags flags = (BindingFlags)
   (BindingFlags.NonPublic | BindingFlags.Instance);
  ConstructorInfo ctor = t.GetConstructor(new Type[0]);
  MethodInfo printer = t.GetMethod("print",flags);
  object a = ctor.Invoke(null);
  printer.Invoke(a, null);
}

А теперь продемонстрируем, как через рефлексию можно получить значение поля объекта. Это достигается путем вызова метода GetField объекта класса Type:

static void GetFieldDemo()
{
  TestClass a = new TestClass();
  BindingFlags flags = (BindingFlags)
    (BindingFlags.NonPublic | 
     BindingFlags.Instance);
  FieldInfo val = 
    typeof(TestClass).GetField("val",flags);
  Console.WriteLine(val.GetValue(a));
}

Генерация метаданных и CIL-кода

Для генерации метаданных в библиотеке рефлексии предназначены классы пространства имен System.Reflection.Emit. Создание новой сборки начинается с создания экземпляра класса AssemblyBuilder. Далее путем вызова методов класса AssemblyBuilder создается нужное количество модулей (объектов класса ModuleBuilder ), в модулях создаются типы (объекты класса TypeBuilder ), а в типах - конструкторы, методы и поля (объекты классов ConstructorBuilder, MethodBuilder и FieldBuilder, соответственно). То есть при генерации метаданных идеология такая же, как и при чтении их из готовой сборки (на рис. 4.6 представлена схема, показывающая последовательность создания метаданных).

В отличие от Metadata Unmanaged API, библиотека рефлексии содержит средства для генерации CIL-кода. Для этого предназначен класс ILGenerator. Он позволяет после создания объекта MethodBuilder (или ConstructorBuilder ) сгенерировать для соответствующего метода (или конструктора) поток инструкций.

В следующем примере библиотека рефлексии используется для генерации сборки .NET, состоящей из одного глобального метода main, выводящего на экран сообщение "Hello, World!":

using System;
using System.Threading;
using System.Reflection;
using System.Reflection.Emit;
class HelloGenerator
{
  static void Main(string[] args)
  {
    AppDomain appDomain = Thread.GetDomain();
    AssemblyName assemblyName = new AssemblyName();
    assemblyName.Name = "hello.exe";
    AssemblyBuilder assembly = 
      appDomain.DefineDynamicAssembly(
        assemblyName,
        AssemblyBuilderAccess.RunAndSave
        );
    ModuleBuilder module = 
      assembly.DefineDynamicModule(
        "hello.exe", "hello.exe"
        );
    MethodBuilder mainMethod =
      module.DefineGlobalMethod(
        "main",
        MethodAttributes.Static |
          MethodAttributes.Public, 
        typeof(void), 
        null
        );
    MethodInfo ConsoleWriteLineMethod = 
      ((typeof(Console)).GetMethod("WriteLine", 
        new Type[] { typeof(string) } ));
    ILGenerator il = mainMethod.GetILGenerator();
    il.Emit(OpCodes.Ldstr,"Hello, World!");
    il.Emit(OpCodes.Call,ConsoleWriteLineMethod);
    il.Emit(OpCodes.Ret);
    module.CreateGlobalFunctions();
    assembly.SetEntryPoint(
      mainMethod,PEFileKinds.ConsoleApplication
      );
    assembly.Save("hello.exe");
  }
}

Сравнение возможностей библиотек

Возможности, предоставляемые библиотекой Metadata Unmanaged API и библиотекой рефлексии, представлены в таблице 4.3.

Из таблицы следует, что ни одна из библиотек, поставляемых вместе с .NET Framework, не позволяет читать CIL-код, хотя эта возможность требуется целому ряду метаинструментов (например, верификаторам и оптимизаторам кода).