Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Программирование под Unix/Linux > Свой скрипт линковщика для модуля ядра

Автор: Relkin 17.6.2010, 14:53

Хочу реализовать в модуле ядра 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 Скрипт примерно следующий (приведён не весь, только значимые части): Код SECTIONS {   .slheader :   {     . = ALIGN(0x10000);     __LOADER_START__ = .;     SHORT (_skinit - __LOADER_START__);     SHORT (__LOADER_END__ - __LOADER_START__);   }   .loader :   {     KEEP(*(.text.__mbheader));     KEEP(*(.text.__start));     KEEP(*(.text._skinit));     *(.text .text.*);     *(.rodata .rodata.*);   }   . = ALIGN(0x4);   __LOADER_END__ = .; } Вопросы: Возможно ли  сделать так, чтобы образ защищённого загрузчика был вкомпилирован в модуль ядра? Как для этого должен выглядеть Makefile и LD скрипт? Нужно ли для этого изменять стандартный (LD скрипт) ? Возможно ли просто включить скомпилированный двоичный код загрузчика в модуль ядра, как это сделать?

Автор: xvr 18.6.2010, 13:57

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

Автор: Relkin 18.6.2010, 19:58

Цитата(xvr @ 18.6.2010,  13:57) Вкомпилировать это в ядро можно, вот только хочется понять зачем? (Не вкомпилировать, а вообще нафига нужен 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'а.

Автор: xvr 18.6.2010, 22:23

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

Автор: Relkin 19.6.2010, 00:01

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

Автор: Relkin 19.6.2010, 00:25

Цитата(xvr @ 18.6.2010,  13:57) а вообще нафига нужен SL? В плане того, как его можно использовать, показательна система flicker. http://sparrow.ece.cmu.edu/group/flicker.html http://sparrow.ece.cmu.edu/group/pub/mccune_parno_perrig_reiter_isozaki_eurosys08.pdf

Автор: xvr 19.6.2010, 12:39

Я это все знаю (за исключением 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 загрузчик особого смысла не имеет, увы

Автор: Relkin 20.6.2010, 16:14

Цитата(xvr @  19.6.2010,  12:39 ) т.к. злоумышленник может просто перехватить исполнение команды SKINIT и проэмулировать работу secure кода (в SKINIT) ВООБЩЕ не прибегая к помощи TPM и аппаратуры. Очевидно, что в этом случае в его (злоумышленника) руках все управление над вроде бы как secure кодом Когда срабатывает skinit он сбрасывает в ноль PCR17 ( при старте компьютера его значение равно -1 ), снимает контрольную сумму с  области памяти, на которую будет передано управление и записывает значение в этот регистр. Всё это выполняется атомарно, работает только одно ядро процессора, прерывания отключены, область памяти с SL защищена от прямого доступа.  Сбросить в ноль значение PCR регистров другим способом никак нельзя ( только испортить ). Таким образом, пользователь всегда может узнать была ли выполнена инструкция SKINIT. Если нет TPM, то всё это не имеет никакого смысла.

Автор: MAKCim 20.6.2010, 21:21

Цитата(Relkin @  17.6.2010,  14:53 ) Возможно ли просто включить скомпилированный двоичный код загрузчика в модуль ядра, как это сделать? Код # objcopy -F <формат модуля ядра> --add-section .slb=<бинарный образ> --set-section-flags .slb=alloc,load,data,code <модуль ядра> <результирующий модуль ядра> в самом модуле сделать Код extern char slb[] __attribute__((section(".slb")));

Автор: xvr 20.6.2010, 21:22

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

Автор: Relkin 21.6.2010, 00:30

Цитата(xvr @  20.6.2010,  21:22 ) Не может - злоумышленник мог отломать в коде проверку результата выполнения SKINIT, и это никто поймать не сможет, т.к. эта проверка будет находится ВНЕ области SL. Кроме того, злоумышленник может реально исполнить SKINIT для получения правильного PCR17, а затем исполнить модифицированную версию SL уже без привлечения TPM и SKINIT для получения требуемого для него результата. Если злоумышленник отламывает проверку -> пользователь понимает что система взломана. В этой схеме  главное не предотвратить взлом системы, а  обнаружить его. Если злоумышленник исполняет skinit [eax], где в регистре указатель на модифицированную версию SL, то на следующей за skinit инструкцией PCR17 уже будет содержать контрольную сумму, снятую с модифицированного SL. Если не принимать в расчёт возможность коллизии хэшей, то получить одинаковые значения PCR для оригинального и модифицированного SL не возможно. Если же skinit передаёт управление на оригинальный SL, то злоумышленник уже никак не может вмешаться в его работу. В конце концов, SL может содержать в себе хэш-код Secure Kernel (SK), и передавать на него управление только в случае совпадения только что снятого и вшитого. Ну, а дальше, соответственно, аттестация. TPM подписывает значения регистров своим приватным ключём -> пользователь (ему известна публичная часть ключа) всегда может проверить, что при загрузке системы использовался TPM. Злоумышленник никак не может узнать приватную часть ключа. Мои знания основываются преимущественно на книге http://www.ibmpressbooks.com/bookstore/product.asp?isbn=0132398427, если не принимать во внимание спецификации. Цитата(xvr @  20.6.2010,  21:22 )  SL & SKINIT для этого не нужны Насколько я понимаю, SKINIT & SL предназначаются для загрузки, например гипервизора (типа HookSafe, Secvisor, Bitvisor, то есть тех, на основе которых строится какая-то системы защиты ОС), во время работы ОС по требованию пользователя. (конечно, вполне возможно есть и какие-то другие им применения см. Open Secure Loader (OSLO)). P.S: просто у меня сложилось впечатление, что у нас с вами несколько разные представления о том, зачем нужен Dynamic root of trust и как он используется.

Автор: xvr 21.6.2010, 15:50

Цитата(Relkin @ 21.6.2010,  00:30) Если злоумышленник отламывает проверку -> пользователь понимает что система взломана. В этой схеме  главное не предотвратить взлом системы, а  обнаружить его.  Если злоумышленник вмешался в процесс раскрутки системы (а без chain of trust это возможно), то он мог установить свой монитор и все дальнейшие действия будут исполняться под его контролем. И он вполне может скрыть все последствия своего вмешательства, и обнаружить его будет невозможно Цитата Если злоумышленник исполняет skinit [eax], где в регистре указатель на модифицированную версию SL, то на следующей за skinit инструкцией PCR17 уже будет содержать контрольную сумму, снятую с модифицированного SL.  Этого он делать не будет - он или подсунет оригинальный SL, или вообще не будет его исполнять Цитата Если же skinit передаёт управление на оригинальный SL, то злоумышленник уже никак не может вмешаться в его работу.  Он может проигнорировать результаты исполнения SL, а взять только посчитанное значение PCR17 Цитата В конце концов, SL может содержать в себе хэш-код Secure Kernel (SK), и передавать на него управление только в случае совпадения только что снятого и вшитого.  А кто мешает злоумышленнику отпэтчить SK и запустить его напрямую, не выполняя SL вообще? Цитата TPM подписывает значения регистров своим приватным ключём -> пользователь (ему известна публичная часть ключа) всегда может проверить, что при загрузке системы использовался TPM. Злоумышленник никак не может узнать приватную часть ключа. А ему (злоумышленнику) и не надо - он вообще может отключить аттестацию и сразу напечатать пользователю правильный ответ Цитата Цитата(xvr @  20.6.2010,  21:22 )  SL & SKINIT для этого не нужны Насколько я понимаю, SKINIT & SL предназначаются для загрузки, например гипервизора (типа HookSafe, Secvisor, Bitvisor, то есть тех, на основе которых строится какая-то системы защиты ОС), во время работы ОС по требованию пользователя.  По моим прочтениям спецификации я понял, что одно из основных назначений SL это исполнение последнего шага в установлении trusted platform (точнее в запуске защищенного супервизора). ПОСЛЕ этого он может запускать и все остальное, что вы перечислили Цитата P.S: просто у меня сложилось впечатление, что у нас с вами несколько разные представления о том, зачем нужен Dynamic root of trust и как он используется. Я понимая что это и как им пользоваться, но по моему он не имеет смысла при отсуствии static root of trust & trust chain (и trusted platform в общем) Какой смысл защищять аппаратно исполнение куска кода (SL), если нет возможности защитить собственно факт АППАРАТНОГО ЗАПУСКА на исполнение этого куска кода (путем перехвата SKINIT)?

Автор: MAKCim 21.6.2010, 16:38

немного не так 1) Код /* module source */ extern char slb[]; ... int init_module() {     void *ptr = slb; ... } ... 2) собираем модуль 3) Код # objcopy -F <формат модуля ядра> --add-section .slb=<бинарный образ> --set-section-flags .slb=alloc,load,data,code <модуль ядра> <результирующий модуль ядра> 4) пишем скрипт Код SECTIONS {     .slb :     {         slb = .;     } } 5) Код # ld -r -T <скрипт> -o <результирующий модуль> <модуль, полученный на шаге 3)>

Автор: Relkin 21.6.2010, 18:57

Цитата(xvr @  21.6.2010,  15:50 ) отключить аттестацию и сразу напечатать пользователю правильный ответ Смысл использования 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: Автор загрузчика http://os.inf.tu-dresden.de/~kauer/oslo/ в своей http://os.inf.tu-dresden.de/papers_ps/kauer07-oslo.pdf указывает, что вполне возможна следующая схема ( Недоверенная ОС (GNU/Linux) ) -kexec-> OSLO -skinit+te-> SL -te-> KERNEL -te-> ...  Аттестация Примечание: SL - это часть OSLO.

Автор: xvr 21.6.2010, 21:11

Цитата(Relkin @  21.6.2010,  18:57 ) Смысл использования SKINIT+TPM как раз и заключается в том, что злоумышленник не знает правильный ответ и никак не может его узнать. Это достигается, во-первых, вводом пользователем не использовавшегося при предыдущих загрузках числа ( его можно передать SL как параметр) (оно необходимо для того, чтобы при каждой загрузке системы итоговый код, предоставляемый пользователю при аттестации получался разным.) Злоумышленник вполне может его перехватить, но это ему никак не поможет, т. к., во-вторых, предоставляемый пользователю код подписан приватной частью ключа TPM, которая никогда не покидает пределы TPM в открытом виде и никому не известна. Это так, но SKINIT и SL для этого не нужны - достаточно воспользоваться ассиметричным шифрованием с резидентным в TPM ключом. Например Случайное число -> Шифрование public ключом -> TPM -> Расшифровка приватным ключом -> Сравнение пользователем Цитата(Relkin @  21.6.2010,  18:57 ) Если расшифрованный и вычисленный ключи совпадают -> при загрузке были использованы только оригинальные компоненты. Так тоже можно, но тогда одним SL не обойтись - все компоненты должны попасть в trust chain Цитата(Relkin @  21.6.2010,  18:57 ) ( Недоверенная ОС (GNU/Linux) ) -kexec-> OSLO -skinit+te-> SL -te-> KERNEL -te-> ...  Аттестация На мой взгляд тут есть дыра. Если злоумышленник запустит свой VMM, то он сможет перехватить управление ПОСЛЕ запуска доверенного кернела (хотя с SKINIT в VMM придется покувыркаться   ).  В любом случае у SRT есть преимущество перед  DRT - в последнем случае злоумышленник имеет возможность поработать ДО запуска trusted platform, и в теории (если найдет дыру) он сможет вмешаться в процесс ПОСЛЕ (через прерывание, DMA, аппаратные регистры платформы и т.д и т.п.) Получаем классическое состязание щита и меча (a-la вирусы и антивирусы). В случае с SRT у злоумышленника такой возможности нет. В общем вы меня убедили - в SL (ТОЛЬКО для раскрутки trusted platform) есть смысл, но одним SL тут не обойтись

Автор: Relkin 21.6.2010, 22:50

Цитата(xvr @  21.6.2010,  21:11 ) Это так, но SKINIT и SL для этого не нужны Смысл использования инструкции заключается в том, чтобы обнулить значение PCR17 ( при старте компьютера, оно равно -1 ), таким образом отвязав последующую процедуру аттестации от текущего состояния системы, и выполнять только один непрерываемый поток инструкций SL'a. Цитата(xvr @  21.6.2010,  21:11 ) На мой взгляд тут есть дыра. Если злоумышленник запустит свой VMM, то он сможет перехватить управление ПОСЛЕ запуска доверенного кернела (хотя с SKINIT в VMM придется покувыркаться  smile ).  Когда выполняетсчя skinit все AP ядра процессора находятся в состоянии после INIT IPI и ждут STARTUP IPI. Работает только BSP ядро с SL, защищённым от всего, в том числе DMA. SL переинициализирует AP ядра процессора своим кодом. После skinit управление уже никогда не вернётся враждебному гипервизору. Всё это, конечно, если она не была сэмулирована, но в обратном случае аттестация не будет пройдена, т.к. обнулить значение PCR17 другим способом никак нельзя.

Автор: xvr 21.6.2010, 23:42

Цитата(Relkin @ 21.6.2010,  22:50) Цитата(xvr @  21.6.2010,  21:11 ) Это так, но SKINIT и SL для этого не нужны Смысл использования инструкции заключается в том, чтобы обнулить значение PCR17 ( при старте компьютера, оно равно -1 ), таким образом отвязав последующую процедуру аттестации от текущего состояния системы, и выполнять только один непрерываемый поток инструкций SL'a. Зачем этот код выполнять именно как SL? Для аутентификации по пользовательскому случайному числу нужен не SL, а не экспортируемый из TPM приватный ключ. Цитата Цитата(xvr @  21.6.2010,  21:11 ) На мой взгляд тут есть дыра. Если злоумышленник запустит свой VMM, то он сможет перехватить управление ПОСЛЕ запуска доверенного кернела (хотя с SKINIT в VMM придется покувыркаться  smile ).  Когда выполняетсчя skinit все AP ядра процессора находятся в состоянии после INIT IPI и ждут STARTUP IPI. Работает только BSP ядро с SL, защищённым от всего, в том числе DMA.  Почему оно защищенное? Если злоумышленник залез в BIOS (а это запросто), то он получит управление до SKINIT, и сможет поставить хук на вызов себя позже (например на другом процессоре, который он может для этого разбудить через STARTUP IPI) Цитата SL переинициализирует AP ядра процессора своим кодом. После skinit управление уже никогда не вернётся враждебному гипервизору.  SL же не бесконечного размера. Выполнение в конце концов покинет защищенную область, вот тут он уже и ждет Цитата Всё это, конечно, если она не была сэмулирована, но в обратном случае аттестация не будет пройдена, т.к. обнулить значение PCR17 другим способом никак нельзя. Злоумышленник может сделать и то и другое. Исполнить SL (с последующим перехватом потока исполнения) для извлечения PCR17, и проэмулировать отпатченный SL для запуска (уже не очень trusted) OS

Автор: MAKCim 22.6.2010, 12:27

Relkin,  xvr,  приятно читать умные диалоги, но некоторый оффтоп все же имеется в данном случае    давайте ближе к linux'у

Автор: Relkin 22.6.2010, 20:51

Цитата(xvr @  21.6.2010,  23:42 ) Почему оно защищенное? Если злоумышленник залез в BIOS (а это запросто), то он получит управление до SKINIT, и сможет поставить хук на вызов себя позже (например на другом процессоре, который он может для этого разбудить через STARTUP IPI) Обычно в DRT под SK подразумевается VMM (гипервизор), который либо начинает контролировать недоверенную ОС (из неё происходил запуск), путём погружения её в виртуальную машину, либо создаёт полностью новые виртуальные машины. Так как GIF флаг равен нулю после SKINIT у AP ядер и они находятся в halted состоянии, то разбудить их возможно только через STARTUP IPI, что и делается либо SL, либо SK. BIOS не может получить управление после SKINIT, до тех пор, пока либо явно не будет обращение к нему, либо при вхождении в SMM. SK (VMM) вполне в состоянии эмулировать BIOS и сбрасывать попытки перейти в SMM (насколько мне известно эмулировать SMM пока получалось только у AMD процессоров). Цитата(xvr @  21.6.2010,  23:42 )  поставить хук на вызов себя позже  Что вы имеете здесь ввиду не знаю, возможно из-за пробелов в знаниях. Вызов на себя позже по прерыванию, по таймеру, или какой-то другой механизм? В моём понимании BIOS это набор процедур, которые могут быть вызваны программным обеспечением. Соответственно, если SK будет эмулировать все обращения к нему из виртуальных машин, то он не получит управления до перезагрузки. Цитата(xvr @  21.6.2010,  23:42 ) Зачем этот код выполнять именно как SL? Для аутентификации по пользовательскому случайному числу нужен не SL, а не экспортируемый из TPM приватный ключ. Вся проблема в том, что DRT стартует из недоверенной среды. Следовательно, если нет доверенного механизма для старта системы (SKINIT), то с одного кода может быть снята контрольная сумма, а после через DMA, враждебный гипервизор, через обновление кэша у процессора, он может быть подменён другим. Соответственно, итоговое число для аттестации получится правильным, но выполнен будет совсем другой код. Наличие SL в цепи загрузки это аппаратное требование, SKINIT передаёт управление на код ограниченного размера. Возможно совместить роль SK и SL, если хватит 64 килобайт. Насколько я понимаю, роль SL, в основном сводится к закрытию памяти SK от DMA, используя либо DEV (только по записи), либо IOMMU.

Автор: xvr 22.6.2010, 21:49

Цитата(Relkin @  22.6.2010,  20:51 ) BIOS не может получить управление после SKINIT, А ему и не надо после, он получает его ДО. Если BIOS модифицирован злоумышленником, то он может сам разбудить AP ДО вызова любого загрузчика и создать там трояна, например переведя AP процессор в PM и перенаправив IDT на приватный кусок памяти с кодом вируса. После чего он может усыпить AP процессор в ожидании STARTUP IPI, который сделает не startup, а запуск вирусного кода. В любом случае DRT позволяет злоумышленнику получить управление ДО вызова SL, и если найдется дыра в системе защиты, то скомпрометировать всю trusted platform. В случае SRT у злоумышленника такой возможности нет, и системе защиты не придется латать потенциальные дыры. Цитата(Relkin @  22.6.2010,  20:51 ) Вся проблема в том, что DRT стартует из недоверенной среды. Следовательно, если нет доверенного механизма для старта системы (SKINIT) Про старт системы речь не шла. Речь шла про аутентификацию пользователя (или его кода). Вариант, когда SL запускает процедуру аутентификации, а потом возвращается обратно (в незащищенную среду) смысла не имеет (вышеупомянутый flicker делает именно это) PS. Мы в оффтопике уже по самые уши, предлагаю завязывать

Автор: Relkin 23.6.2010, 07:23

Цитата(xvr @  22.6.2010,  21:49 ) А ему и не надо после, он получает его ДО. Если BIOS модифицирован злоумышленником, то он может сам разбудить AP ДО вызова любого загрузчика и создать там трояна, например переведя AP процессор в PM и перенаправив IDT на приватный кусок памяти с кодом вируса. После чего он может усыпить AP процессор в ожидании STARTUP IPI, который сделает не startup, а запуск вирусного кода. Все мои комментарии выше написаны с учётом того, что система не доверена(любые виды зловредов + сама ОС с закладками). То есть до, сколько угодно, после - только под контролем гипервизора ( попытки запустить враждебный гипервизор можно либо сбрасывать, либо делать эмуляцию этих команд). skinit атомарна и отключает прерывания, команда startup ipi требует указания ей адреса, по которому расположен код инициализации процессора. То, что вы описали не получится ( то есть изменить IDT можно, но SL или SK всё равно выполнит свой код). Цитата(xvr @  22.6.2010,  21:49 ) а потом возвращается обратно (в незащищенную среду) смысла не имеет (вышеупомянутый flicker делает именно это) Можно и не возвращаться, а, например, если SK - XEN, развёртывать полностью новое окружение поверх текущего. Fliсker позволяет выделить критические части у ПО, выполнить их в изолированной среде, а после аттестовать. После он возвращает управление в недоверенную среду, но цель у него и не ставилась как защитить всю систему. В конце концов, можно запихнуть в гипервизор антивирус или http://www.citforum.ru/operating_systems/transparent_rpc/, таким образом защитив их от враждебной ОС. Цитата(xvr @  22.6.2010,  21:49 ) PS. Мы в оффтопике уже по самые уши, предлагаю завязывать Согласен.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)