Хочу реализовать в модуле ядра Secure Loader.

AMD Manual
15.26.2  Secure Loader Image
The secure loader (SL) image contains all code and initialized data sections of a secure loader. This
code and initial data are used to initialize and start a security kernel in a completely safe manner,
including setting up DEV protection for memory allocated for use by SL and SK. The SL image is
loaded into a region of memory called the secure loader block (SLB) and can be no larger than
64Kbyte (see “Secure Loader Block” on page 415). The SL image is defined to start at byte offset 0 in
the SLB. The first word (16 bits) of the SL image must specify the SL entry point as an unsigned offset into the
SL image. The second word must contain the length of the image in bytes; the maximum length
allowed is 65535 bytes. These two values are used by the SKINIT instruction. The layout of the rest of
the image is determined by software conventions. The image typically includes a digital signature for
validation purposes. The digital signature hash must include the entry point and length fields. SKINIT
transfers the SL image to the TPM for validation prior to starting SL execution (see “SKINIT
Operation” on page 417 for further details of this transfer). The SL image for which the hash is
computed must be ready to execute without prior manipulatio

Скрипт примерно следующий (приведён не весь, только значимые части):


Вопросы:

• Возможно ли  сделать так, чтобы образ защищённого загрузчика был вкомпилирован в модуль ядра?
  Как для этого должен выглядеть Makefile и LD скрипт? Нужно ли для этого изменять стандартный (LD скрипт) ?
• Возможно ли просто включить скомпилированный двоичный код загрузчика в модуль ядра, как это сделать?

Вкомпилировать это в ядро можно, вот только хочется понять зачем? (Не вкомпилировать, а вообще нафига нужен SL)?
Вся эта секьюрная тягомотина не имеет смысла без выстроенной trust chain в TPM. А для этого нужна специальная ОС, которая бы это поддерживала, начиная с бута BIOS'а (насколько мне известно, таких пока нет)

Вы говорите о Static root of trust. В спецификации TPM v 1.2 есть Dynamic root of trust, в этом случае нужен SL.
Проекты такие есть. ( см tboot, TrustedGRUB, GRUB TCG Patch to support Trusted Boot URL: http://trousers.sourceforge.net/grub.html )
Все они как раз стартуют из bios'а.

Интересно. А какое планируется применение этой фиче? Я честно говоря не могу себе представить ЗАЧЕМ это все нужно. (Спецификация TXT и TPM ответа на вопрос ЗАЧЕМ не дают, они только говорят КАК)

После загрузки проводится процедура аттестации. TPM подписывает значения PCR регистров, в которых хранятся хэши компнентов ( BIOS->LOADER->KERNEL->init->... ), приватным ключём. Пользователь знает хэши всех компонентов, и публичную часть ключа TPM, соответственно, он может повторить вычисления на автономном доверенном устройстве. Иногда ( я не знаю как точно в приведённых выше проектах ) в какой-то момент  у пользователя спрашивается уникальное число, которое не использовалось при предыдущих загрузках, оно складывается с значениями регистров. Случайное число необходимо для обеспечения уникальности каждой процедуры загрузки системы. Пользователю выводится на экран итоговое число. Он его проверяет. Если совпадает -> в процессе загрузки системы не были использованы недоверенные компоненты, загрузка происходила в точной последовательности ( bios->mbr->bootloader->kernel->init -> .... ) и ни один из исполняемых файлов не был подменён. Я привёл наиболее краткий и общий процесс загрузки, у TPM большое количество возможностей которые также могут использоваться при загрузке (Sealed Storage, Remote attestation, проверка аппаратной конфигурации ( например, если не совпадает с заданной -> не расшифровывать данные на жёстком диске) ).

В любом случае, у меня несколько иная задача и именно статической загрузкой я никогда не занимался, поэтому могут быть некоторые неточности.

В плане того, как его можно использовать, показательна система flicker.

http://sparrow.ece.cmu.edu/group/flicker.html

Flicker: An Execution Infrastructure for TCB Minimization

Я это все знаю (за исключением flicker, спасибо за ссылку). Но это отвечает на вопрос КАК, но не отвечает на вопрос ЗАЧЕМ.   
Главное предназначение системы TXT (by Intel) - обеспечить неизменную платформу исполнения, что автоматически ставит крест на всех update'ах и patch'ах системы (хотя они и вполне легальны).

Для нормальной работы системы необходимы Root of trust и Chain of trust. Т.е. исполнение начинается с доверенного модуля (boot block в BIOS). Он не может быть изменен НЕ ПРИ КАКИХ ОБСТОЯТЕЛЬСТВАХ. Каждый блок загрузки СНАЧАЛА проверяет следующий (через PCR), и только потом его запускает. Таким образов вся цепочка становится доверенной
Заканчивается эта цепочка вызовом SKINIT (SENTER by Intel), который проверяет код (поддерживая таким образом chain of trust), а потом исполняет его. Этот код переводит систему в режим виртуализации. Монитор VM (он уже загружен одним из trusted вызовов в цепочке) создает защищенную VM, все потенциально опасные действия в которой перехватываются монитором VM, создавая таким образом Trusted Platform, в которой уже раскручивается обычная ОС

Подход flicker (без построения chain of trust и использования динамических PCR) не работает, т.к. злоумышленник может просто перехватить исполнение команды SKINIT и проэмулировать работу secure кода (в SKINIT) ВООБЩЕ не прибегая к помощи TPM и аппаратуры. Очевидно, что в этом случае в его (злоумышленника) руках все управление над вроде бы как secure кодом   

В статье есть ссылка на размер кода для построения chain of trust и запуска VMM - 50К строк (в существующем менеджере VMM - XEN)

Так что сам по себе SL загрузчик особого смысла не имеет, увы   

Когда срабатывает skinit он сбрасывает в ноль PCR17 ( при старте компьютера его значение равно -1 ), снимает контрольную сумму с  области памяти, на которую будет передано управление и записывает значение в этот регистр. Всё это выполняется атомарно, работает только одно ядро процессора, прерывания отключены, область памяти с SL защищена от прямого доступа.  Сбросить в ноль значение PCR регистров другим способом никак нельзя ( только испортить ). Таким образом, пользователь всегда может узнать была ли выполнена инструкция SKINIT. Если нет TPM, то всё это не имеет никакого смысла.

в самом модуле сделать

Злоумышленник может не дать сработать SKINIT, и вся дальнейшая защита уже работать не будет.
Не может - злоумышленник мог отломать в коде проверку результата выполнения SKINIT, и это никто поймать не сможет, т.к. эта проверка будет находится ВНЕ области SL. Кроме того, злоумышленник может реально исполнить SKINIT для получения правильного PCR17, а затем исполнить модифицированную версию SL уже без привлечения TPM и SKINIT для получения требуемого для него результата.
Без TPM вообще вся эта машинерия не работает. А без chain trust от root of trust не имеет смысла SL
С помощью TPM без chain of trust можно сделать авторизацию, криптование и пр., привязанные к конкретной машине (экземпляру TPM). SL & SKINIT для этого не нужны

Если злоумышленник отламывает проверку -> пользователь понимает что система взломана. В этой схеме  главное не предотвратить взлом системы, а  обнаружить его. Если злоумышленник исполняет skinit [eax], где в регистре указатель на модифицированную версию SL, то на следующей за skinit инструкцией PCR17 уже будет содержать контрольную сумму, снятую с модифицированного SL. Если не принимать в расчёт возможность коллизии хэшей, то получить одинаковые значения PCR для оригинального и модифицированного SL не возможно. Если же skinit передаёт управление на оригинальный SL, то злоумышленник уже никак не может вмешаться в его работу. В конце концов, SL может содержать в себе хэш-код Secure Kernel (SK), и передавать на него управление только в случае совпадения только что снятого и вшитого. Ну, а дальше, соответственно, аттестация.

TPM подписывает значения регистров своим приватным ключём -> пользователь (ему известна публичная часть ключа) всегда может проверить, что при загрузке системы использовался TPM. Злоумышленник никак не может узнать приватную часть ключа.

Мои знания основываются преимущественно на книге Practical Guide to Trusted Computing, если не принимать во внимание спецификации.



Насколько я понимаю, SKINIT & SL предназначаются для загрузки, например гипервизора (типа HookSafe, Secvisor, Bitvisor, то есть тех, на основе которых строится какая-то системы защиты ОС), во время работы ОС по требованию пользователя. (конечно, вполне возможно есть и какие-то другие им применения см. Open Secure Loader (OSLO)).
P.S: просто у меня сложилось впечатление, что у нас с вами несколько разные представления о том, зачем нужен Dynamic root of trust и как он используется.

Это сообщение отредактировал(а) Relkin - 21.6.2010, 01:54

Если злоумышленник вмешался в процесс раскрутки системы (а без chain of trust это возможно), то он мог установить свой монитор и все дальнейшие действия будут исполняться под его контролем. И он вполне может скрыть все последствия своего вмешательства, и обнаружить его будет невозможно
Этого он делать не будет - он или подсунет оригинальный SL, или вообще не будет его исполнять
Он может проигнорировать результаты исполнения SL, а взять только посчитанное значение PCR17
А кто мешает злоумышленнику отпэтчить SK и запустить его напрямую, не выполняя SL вообще?
А ему (злоумышленнику) и не надо - он вообще может отключить аттестацию и сразу напечатать пользователю правильный ответ

По моим прочтениям спецификации я понял, что одно из основных назначений SL это исполнение последнего шага в установлении trusted platform (точнее в запуске защищенного супервизора). ПОСЛЕ этого он может запускать и все остальное, что вы перечислили
Я понимая что это и как им пользоваться, но по моему он не имеет смысла при отсуствии static root of trust & trust chain (и trusted platform в общем)

Какой смысл защищять аппаратно исполнение куска кода (SL), если нет возможности защитить собственно факт АППАРАТНОГО ЗАПУСКА на исполнение этого куска кода (путем перехвата SKINIT)?

немного не так

1)


2) собираем модуль

3)


4) пишем скрипт


5)

Смысл использования SKINIT+TPM как раз и заключается в том, что злоумышленник не знает правильный ответ и никак не может его узнать.
Это достигается, во-первых, вводом пользователем не использовавшегося при предыдущих загрузках числа ( его можно передать SL как параметр) (оно необходимо для того, чтобы при каждой загрузке системы итоговый код, предоставляемый пользователю при аттестации получался разным.) Злоумышленник вполне может его перехватить, но это ему никак не поможет, т. к., во-вторых, предоставляемый пользователю код подписан приватной частью ключа TPM, которая никогда не покидает пределы TPM в открытом виде и никому не известна.

Пользователь, получив код, расшифровывает его, используя публичную часть ключа TPM -> точно знает, что код пришёл от TPM, а не предоставлен злоумышленником.
Пользователю известны число, которое он вводил, и контрольные суммы компонент, использовавшихся при загрузке. Он повторяет операции ( SL_HASH | RAND_NUM |  SK_HASH | ... ) на автономном доверенном устройстве ( телефоне, калькуляторе, другом компьютере, ... ). Если расшифрованный и вычисленный ключи совпадают -> при загрузке были использованы только оригинальные компоненты.
Эмулировать инструкцию SKINIT можно, но при этом не удастся пройти аттестацию.


Static root of trust (SRT) и Dynamic root of trust (DRT) разные механизмы, которые могут быть использованы для достижения одиниковых целей. Например:
(-te-> обозначение операции TPM_Extend, которая выполняется прежде чем передаётся управление ) 

SRT: (Доверенная, неперепрошиваемая, часть BIOS) -te-> BIOS -te-> MBR -te-> BOOTLOADER -te-> KERNEL -te-> ... -> Аттестация

DRT: Автор загрузчика OSLO в своей публикации указывает, что вполне возможна следующая схема
( Недоверенная ОС (GNU/Linux) ) -kexec-> OSLO -skinit+te-> SL -te-> KERNEL -te-> ...  Аттестация
Примечание: SL - это часть OSLO.

Это сообщение отредактировал(а) Relkin - 21.6.2010, 19:57

Это так, но SKINIT и SL для этого не нужны - достаточно воспользоваться ассиметричным шифрованием с резидентным в TPM ключом. Например Случайное число -> Шифрование public ключом -> TPM -> Расшифровка приватным ключом -> Сравнение пользователем

Так тоже можно, но тогда одним SL не обойтись - все компоненты должны попасть в trust chain

На мой взгляд тут есть дыра. Если злоумышленник запустит свой VMM, то он сможет перехватить управление ПОСЛЕ запуска доверенного кернела (хотя с SKINIT в VMM придется покувыркаться   ). 

В любом случае у SRT есть преимущество перед  DRT - в последнем случае злоумышленник имеет возможность поработать ДО запуска trusted platform, и в теории (если найдет дыру) он сможет вмешаться в процесс ПОСЛЕ (через прерывание, DMA, аппаратные регистры платформы и т.д и т.п.) Получаем классическое состязание щита и меча (a-la вирусы и антивирусы). В случае с SRT у злоумышленника такой возможности нет.

В общем вы меня убедили - в SL (ТОЛЬКО для раскрутки trusted platform) есть смысл, но одним SL тут не обойтись