> Вы уверены, что сможете с первого раза написать идеальный прелоадер без ошибок? Ну, во первых, с 1 раза и не надо - зачем вам устраивать локаут себе на тестово дебажных версиях? А вот после проверки что все ЗБС - гайки завинтить :)
Во вторых - если вы не можете написать без факапов даже, блин, 440-байтный код :D, тогда вам придется наверное признать что это - не ваше! :D Нене, рассаду выращивать я вам советовать не буду, там можно встать на грабли или порезаться огурцом.
В третьих, если ну очень хочется - я ж описал вариант где хардварно снимается WP и вперед, апдейтить. Сие потребует нажать кнопу или переставить джампер, подтвердив физическое присутствие. Гугол так на хромобуках делал, неплохо придумано. И сильная защита от ремотных физиономий, которые кнопку нажать все же не могут, и можно сделать полный оверрайд на вообще свой код с самого начала, зажав эту кнопку. Ну а дальше вы уже отвечаете за безопасность системы сами и гугл умывает руки, теперь это целиком ваше добро.
> Я скорее всего не смогу, и хотелось бы расчитывать на какую-то
> внешнюю систему для проверки подписи, дающей возможность выпустить новую версию (и
> заодно отозвать старую).
Ну вот вам и подогнали счастья. Только в результате как это и бывает оно в результате как-то делает больше всего фавора в общем то и не вам, а для вас только достаточно декоративная иллюзия контроля. А своим хозяевам эта пакость фавор норовит сделать и не спрашивая вас особо. При том это идет настолько далеко, что хозяева отказываются даже минимально щемить себе йайцы, поскольку их видите ли за это натягивают злые кастомеры. И они как-то вот решают что лучше нехай вам хакеры грузят черти-что через буткит касперского чем у их кастомеров компы закирпичатся. И безопасТность полчается в результате характерная - у юзера куча грабель, особенно если он удумал шаг в сторону, хакеры вообще не имеют проблем, а тут еще какие-то вендоры в режиме супербогов порой объясняют с п0нтом под з0нд0м что на свежекупленый ноут вы имеете право поставить либо вон ту восьмерку, либо вон тот рхел. И хватит с вас!
> Когда в ROM обнаруживается ошибка, всё становится очень плохо.
На этот случай я описал вариант с WP# где если сильно надо, он снимается. Но только локальным физически присутствующим телом с полным доступом к железке - такой мог и рентгеном пшикнуть вовремя, если сильно надо.
> Но у производителя чипов больше ресурсов, чем у меня (и у большинства разработчиков ОС),
> поэтому это должно происходить не слишком часто.
И что характерно - они предпочли эти ресурсы использовать не для защиты юзерей от проблем, а для навязывания что вы можете и не можете. Бабло побеждает зло. Эта мышиная возня была затеяна в основном потому, что MS лавры фирмы Эпл покоя не дают. Им кажется хочется загнать всех в стор и заставить покупать софт и контент только там.
> Представьте, что вы работаете в компании, и в ваши обязанности входит обслуживание
> рабочих мест сотрудников, которых сотни.
Представьте, что вы работаете в компании. А теперь представьте что малваре ... тихой сапой закрепится на десяточке из компов, в регионах памяти где никакой антивирь это в принципе вышибить не может. А, погодите, всякие equation примерно так и делают, ололо :)
> Вот вышла новая версия ОС, в которой обновились критические компоненты (в частности
> ядро). Как массово накатить обновление?
Упомянутая схема вообще никак не мешает апдейтить что либо - покуда вы можете подписать это (или оно подписано доверенным ключом). Это "навесной вариант secure boot", где железный root of trust создается нами, известно из чего и понятно почему ему можно доверять. А когда это чей-то ME ROM и огромное блобваре где черт ногу сломит - это довольно голимый root of trust. На гнилом фундаменте нельзя построить хороший дом.
> С boot update password конечно всё здорово придумано, но в PC такого пока что нет
> (что-то похожее есть на новых маках). Зато есть Secure Boot, который эту проблему
> решает. Вместо password используется подпись.
Вон тот password (или нажатие кнопки для снятия WP#) надо только для апдейта "root of trust" (начальной фазы загрузки, смыслового аналога boot ROM). В более поздних фазах когда все уже раскочегарено можно юзать и обычные подписи уже, после того как root of trust проверил что ему те ключи более поздних фаз катят, конечно. Всякие ME и бутгады тоже так делают - там вшит хэш убер-мастер-ключа, обычно куда-то в OTP ROM ("efuses"). И начальный ром проверяет что у первого ключа хэш вот такой. Тот кто владеет этим ключом и является настоящим owner'ом. И как вы уже поняли это ессно не вы.
В ARM чипы часто идут с фабы чистыми - fuses не прошиты, и можно вообще активировать секурбут самому и вшить хэш именно своего мастерключа. На x86 (и некоторых ARM) таки решили что морда у вас таких красивых от такого контроля и такой безопасности все же треснет - так что это отжимает себе вендор, а вам голимненькая иллюзия что вы там чем-то типа-управляете.
А изначально вопрос был можно ли и как что-то такое сделать с MBR или чем-то подобным. Ну вот я и показал что да, можно и с чем-то таким, если сильно хочется. Понадобится media которую можно сделать readonly. В случае ARM, даже без активированного секурбута в железе, такая схема может быть довольно эффективна т.к. глуповатый бутром чипа только пинает наш бут с карты или spi флехи, и если вот это будет readonly, никаких проблем рассмотреть вот этот бут как root of trust где допустим вшит тот хэш начального мастерключа которым подписана следующая стадия. Такой себе "rom extension" с "навесным секурбут". А если очень сильно хочется то вот для spi rom его можно даже разрещить обновлять - если вон тот микроконтроллер по пути не отдающий свое содержимое наружу вдруг согласится махнуть лапкой правильно и разлочить чип на запись.
> Не получится. Всё, что знает BIOS - это то, что с диска
> надо загрузить первый сектор и передать туда управление.
Прекрасно - BIOS прочитает _READONLY_ лоадер. Хакер не сможет пропатчить это и сломать его логику. Этот лоадер дочитает из _READONLY_ зоны второй, более жирный и умный модуль. Хакер не может пропатчить и это. А вот этот модуль уже сможет и развернуть публичное крипто, и в себе вхардкодить мастеркей, которым подписаны следующие фазы. И поскольку оно readonly - заменить на свое хакеру это не катит. И придется жить с хэшом мастеркея которого у хакера нет, он видите ли где-то в загашнике. Ну вот такой навесной root of trust. Сие предполагает некие допущения, но то что это хуже того месива которое в uefi развели - можно поспорить.
MBR, видите ли, достаточно прост и туп для того... чтобы не стоять на пути почти любой идеи которая пришла в голову. А вот о наглом и интрузивном секурбуте это уже не скажешь.
> Что будет грузиться дальше, какой layout у выдуманных мной структур, ему уже неизвестно.
Это не важно. Важно чтобы 440 байтов были ваши, делали что вам надо и их нельзя было заменить на хакерские. И если сие безусловно подчитает из readonly зоны еще 100500 байтов, допустим, сразу после того бутсектора, то чего? Хакер не может патчить и это - и дальнейшее целиком на усмотрение этого кода. Если тот код решит в себе вхардкодить хэш мастерключа или даже всю публичную часть и будет далее запускать только то что им подписано - собственно, а как это оспаривать?! Покуда это readonly media, с которой биос грузится - сорян, но эта штука haves control и вполне может стать самопальным root of trust. Который нельзя вот так просто и нахрапом заменить, как и тот убер-ключ в boot rom, собссно :)
> Значит единственное место, у которого он сможет проверить подпись (если бы такая
> функция была бы реализована) — это IPL.
BIOS (или глуповатому boot ROM ARM чипа, ... ) вообще не надо ничего в этом месте проверять.
В этом случае, в этот момент доверие строится на том факте что вон то - именно наглухо READONLY media. Где хакер не может сменить код на что-то более полезное и кооперативное для себя - и поэтому данный код вполне катит как начальный якорь root of trust. При этом разумеется надежность этой штуки равна эффективности энфорса readonly. Это же касается и bios/boot rom запускающего сие шоу. В случае ARM с накристальным ROM сие достаточно неубиваемо - перешивать maskROM еще никто не научился, так что переубедить того вгрузить другой сектор с более полезным хакеру кодом - не выйдет. С BIOS - там вариантов больше, но это потребует продвинутый хакинг биоса и резко взвинчивает уровень атаки. Ну и если на то пошло, WP# и на флехе с биосом есть, можно и его в жесткий ридонли загнать, если системное фирмваре на такое не обидится. Корбут не обидится, bios/uefi - зависит от.
Рассматривайте действия биоса как "HW sequence" который слепо доверяет нашей первой фазе. Так же как чип ME или вон тот ARM слепо доверяет своему boot ROM, просто начиная исполнять это при ресете, полагаясь на тот факт что этот код в readonly зоне которая не меняется. А вот наша первая фаза может взять root of trust в свои лапы.
> Чтобы построить цепочку доверия, внутри этого IPL должен располагаться код, который
> загрузит всё остальное, проверит подпись и передаст управление в случае успеха.
Нет. В этот момент доверие в той схеме все еще держится на том факте что и довесок догружаемый мелким лоадером - все еще readonly.
Вообще, так можно и всю систему поднять - положить систему на, допустим, SD карту, запросить readonly на носитель после этого (у SD есть такая фича) - и усе, атакующий ничего сделать с этой штукой в принципе не сможет. Система всегда будет в том виде как она задумана. Западло состоит в том что это будет неудобно юзеру - и катит только для сильно некоторой встраиваемой мелочи. Где есть железная уверенность что слепленый образ 1 раз и навсегда. Для обычного компа это дубово и неудобно - и поэтому в какой-то момент надо все же что-то разрешить что-то обновлять. Иначе это слишком уж жестко и неудобно. Кроме того при этом не получится заапдейтить систему. Лулз состоит в том что малварь даже при дырах не может закрепиться в системе и ресет вышибает гуано наповал, см как это с мыльницами всякими работает.
> А места для этого маловато.
Только из-за узости вашего мышления. У вас столько места сколько вы захотите, покуда READONLY блок подчитывает другой READONLY блок и это остается именно READONLY, так что хакер не может заменить логику всего этого на более кооперативную. В этом месте контроль у того кода и никакой обход этой логики не предусмотрен. Если 440 байт лоадер откажется читать довесок, вы пролетаете, boot failed. Если довесок откажется запускать следующую стадию, вы опять же пролетаете. И что-то по этому поводу предпринять можно разве что локальной заменой readonly чипа/карты/чтотамувас, но там и много чего еще можно предпринять.
> Так что остаётся только вариант с уводом в read-only, а
> обычный PC с обычными жёсткими дисками так (увести в r/o первые N килобайт) не умеет.
Зато он допустим умеет грузится с, например, SD карты (как минимум через usb ридер). И вот оно умеет в RO целиком уходить по одной из команд SD спеков. Ну и вот будет такая R/O бутявка, с бутлоадером который root of trust. Ну да, послать ту команду - надо mmc хост или микроконтроллер, ридеры при гейтовании mass storage -> SD такими абстракциями не оперируют, конечно. И собссно SD карточка достаточно дешевая и простая чтобы ее и целиком под "boot ROM area" отдать, не? И ей даже супербыстрой или емкой быть не надо - по минимуму только 440 байтов и оверлей, just enough чтобы прочекать чтонить на writeable носителе :)
Алсо можно сделать себе usb-бутявку из какого-нибудь МК, где фирмварь может вообще обычную запись mass storage - unimplemented. А образ залить иначе (своим протоколом, инклудом в фирмвару). И хрен оспоришь. А если сильно хочется поиздеваться над хакерами, можно даже запретендовать что запись типа-прошла, ггг.
>> Смысл всей этой гадости - убедить лоха в том что у него типа-есть-контроль.
> Смысл всех этих мер не в абсолютной защите от всех-всех подряд.
И есть один нюанс. Эта штука большая и навороченная. И поэтому в ней много багов. Я видел, как один легендарный грандмастер вынес такую схему, да еще куда более секурный вариант. Нет, он не нашел переполнение буфера. Нет, он не сменил мастер ключ. Но он качественно наел RSA одним маленьким фокусом с экспонентой. Проверки прошли - и код грандмастера стал для девайса родным. Это то что вы получаете за навороченные алгоритмы и индусню не имеющую понятия как это работает. Небольшой щелк пальцами того кто понимает - и вся навороченая
> От производителя процессора вы всё равно защититься не сможете.
А тут вопрос в том атакует ли он. И если да - возможно надо сменить процессор. Или даже в совсем пиковой ситуации - стать производителем, если других вариантов не осталось.
> Все эти меры, правильным образом задеплоенные, позволяют защититься всего от двух атак:
> 1) злоумышленник смог кратковременно получить контроль, и, переписывая критические
> компоненты системы, хочет закрепиться надолго;
Как-то так. Упомянутые фортели тоже от чего-то такого в основном. Хотя в случае с МК например можно и более злостно потрепыхаться: при защите от чтения ключ уже не вытаскивается наружу. И если например диск пошифровать, сделав какой-нить key exchange, если МК будет не в настроении, доступ к системе будет урыт не только на модификацию, но и на изучение содержимого. Что впрочем не сильно спасет от случая когда хакер влез в систему где уже все подцеплено.
> 2) компьютер является частью какой-то распределённой системмы; пользователь этого компьютера
> и есть злоумышленник — он выкинул рабочий компьютер и заменил его
> (по частям или целиком) своим, и пытается выдать его за оригинальный,
> чтобы украсть или исказить данные этой системы.
Это вообще идиотия какая-то - нормальные распределенные системы делают так, чтобы это просто не было проблемой. Не верите? Окей, попробуйте обмануть биткоин. Потратить одни и те же коины дважды уже может вас озолотить нахрен, одним чихом. Удачи :)
> Intel, разумеется, может провернуть любую из этих атак, и является стороной, которой
> мы вынуждены доверять.
Звучит прикольно для господ оставивших главный ключ себе. Ну, доверяйте. А я пешком постою таким entity "доверять".
> Заметьте, что Intel сделал ME, микрокод и много ещё что обновляемым, чтобы
> сохранить возможность исправлять свои собственные ошибки.
Даже Intel не может обновить boot ROM ME. Даже эпл не может запатчить boot ROM. И кстати поскольку они набили туда довольно много гуано - им за это недавно таки прилетело. И таки они ничерта с этим не сделают до перевыпуска новых ревизий чипов с новым ROM, а старые девайсы будут подлежать takeover'у вечно.
> Путь "сделать с первого раза всё правильно и увести в readonly" слишком сложный.
Но интел именно это и сделал для своего ME boot ROM... как и многие иные процы. Когда вы только включаете питание, проц должен знать что ему делать и откуда-то взять это знание.
Надеюсь это объясняет почему я люблю железки где boot ROM умеренного размера и худо-бедно проанализирован.
> Если не быть активистом фонда СПО, то в ME нет ничего особенно плохого.
Если включить мозг, чужой убер-привилегированный компонент с мутным НЕЗАМЕНЯЕМЫМ мной кодом, всегда работающим side by side и даже на выключеном компе - пожестче иных оруэлловских фантазий.
> vPro по-умолчанию выключен.
Это всего лишь какие-то довески на тот же ME. И что все эти мегазы блобазов с целой операционкой в комплекте реально умеют - можно подумать кто-то блин сильно анализировал.
> На мой взгляд, единственное, что в ME работает лично против меня, это возможность
> по-разному инициализировать одинаковые кристаллы,
А мне вот лично очень не нравится что резидентно висящая на отдельном проце операционка (!!!) может шарахаться допустим в RAM моей системы - да, эта штука умеет в DMA, и поэтому может просто пойти и стырить допустим вон тот пароль из памяти, если вдруг захочет. А захочет ли оно или нет - да кто эти мегазы знает? Можно подумать их кто-то в таком объеме штудировал. А когда таки штудируют - мадам Рутковска нам и показывает "ring -3 rootkit", а интель затыкает CVE в этсамом.
Ну и вообще, когда я плачу как за собственность а в результате главный ключ мне не дают - и это в принципе не оверрайдится - тут по-моему все предельно понятно кто кого за кого держит.
> выше), так как у ME не было бы возможности доказать свою собственную подлинность.
А на мой вкус он должен доказывать подлинность только мне, только моего кода. А если он вместо этого видите ли на wintel работать удумал, за мои же бабки - он тогда в общем то враг. И пучок рентгена ему в табло, по большому то счету.
> Так что можно рассматривать процессор Intel и блоб Intel
> ME, как единый программно-аппаратный комплекс.
Я предпочитаю это рассмтривать как программно-аппаратный бэкдор. Больше всего оно похоже на вот это.
> доверять. Но в большинстве случаев их можно выкинуть, а то и
> вовсе заменить весь биос на открытый coreboot.
Тем не менее, даже coreboot не снимает полностью проблемы с ME. Так что в долговременном плане я для себя хочу отделаться от x86 насовсем. Задолбали.
> Так можно договориться до того, что я не могу изменять топологию интегральных
> (микро)схем, и поэтому у меня недостаточно контроля.
Ну вообще, когда корпорации типа интела начинают феерично борзеть и заниматься именно вот таким - именно это и приходит в бошку толпе народа. Начинают активно развиваться толпы альтернативных SoC, открытые ядра, периферия, народ учится рисовать крутые печатки опенсорсным софтом, клепать открытыми тулсами прошивки FPGA, ...
И я думаю что с железом произойдет примерно то же что и с софтом. По примерно тем же причинам. Проприетарный софт толпа народа решила вынести в основном потому что он стал оборзелым куском головняка, полагающим что с нахрапом навязывать ультра-идиотские правила игры - катит.
> Контроля достаточно для того, чтобы собрать новый образ ОС, подписать его и разлить по всем
> маишнам. А также обновить все обновляемые блобы.
Иллюзия конечно забавная, но всего лишь иллюзия. Это как с кольцами Саурона. Ваши мелкие незначительные ключи - ничто против грандмастерского ключа, который шутя перекрывает все остальное одной левой. Можете махать вашими побрякушками до упада - но вы ничто против Саурона.
