The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Утечка 20ГБ внутренней технической документации и исходных текстов Intel, opennews (??), 07-Авг-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


14. "Утечка 20ГБ внутренней технической документации и исходных т..."  +6 +/
Сообщение от Аноним (14), 07-Авг-20, 10:48 
Вся эта утечка как минимум поможет проекту coreboot.
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

26. "Утечка 20ГБ внутренней технической документации и исходных т..."  +3 +/
Сообщение от Дмитрий (??), 07-Авг-20, 11:19 
Скорее всего, будут проблемы из-за этого.
Wine, например, не принимает патчи от разработчиков, которые видели исходный код Windows или работали в Microsoft
Ответить | Правка | Наверх | Cообщить модератору

46. "Утечка 20ГБ внутренней технической документации и исходных т..."  +/
Сообщение от SR_team (ok), 07-Авг-20, 12:07 
однако очень удачно совпало, что после слития сурсов старой винды, вайн стал развиваться заметно быстрее, а регрессии практически перестали появляться
Ответить | Правка | Наверх | Cообщить модератору

110. "Утечка 20ГБ внутренней технической документации и исходных т..."  +3 +/
Сообщение от Александр (??), 07-Авг-20, 15:38 
Совпадение, там просто valve начали поддерживать разработку, как кадрами, так и деньгами
Ответить | Правка | Наверх | Cообщить модератору

69. "Утечка 20ГБ внутренней технической документации и исходных т..."  +3 +/
Сообщение от Аноним (69), 07-Авг-20, 12:45 
Так для этого есть схема при которой один читает утекший код, рассказывает на словах второму, а тот пишет код на этой основе, назвается "Двойной слепой метод" кажется. И это часто применяется для реверс инжиниринга.
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

72. "Утечка 20ГБ внутренней технической документации и исходных т..."  +2 +/
Сообщение от exstrim401email (ok), 07-Авг-20, 12:51 
Clean room design
Ответить | Правка | Наверх | Cообщить модератору

80. "Утечка 20ГБ внутренней технической документации и исходных т..."  +/
Сообщение от Michael Shigorinemail (ok), 07-Авг-20, 13:12 
Собственно, не-IBM-овские BIOS для "IBM PC Compatible" так и появились, насколько помню.
Ответить | Правка | Наверх | Cообщить модератору

193. "Утечка 20ГБ внутренней технической документации и исходных т..."  +/
Сообщение от Аноним (193), 08-Авг-20, 15:50 
Не совсем. Реверсеры читали не ЯВУ,  а машкоды и выхлоп дизассемблера.
Ответить | Правка | Наверх | Cообщить модератору

73. "Утечка 20ГБ внутренней технической документации и исходных т..."  +1 +/
Сообщение от Аноним (73), 07-Авг-20, 12:59 
При прямом заимствовании (сиречь копировании) кода - да могут.
Но если использовать референсный код и доки для понимания принципов работы и на их основе реализовывать - проблем быть не должно.
В основном проблемы биосописателей - это именно отсутствие доступной документации на железо вообще и на всякие процессы инициализации/сна/пробуждения в частности.
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

171. "Утечка 20ГБ внутренней технической документации и исходных т..."  +/
Сообщение от Соня Мармеладова (?), 07-Авг-20, 23:04 
А от тех, кому Шаляпин напел?)
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

70. "Утечка 20ГБ внутренней технической документации и исходных т..."  +4 +/
Сообщение от Аноним (86), 07-Авг-20, 12:49 
В этой утечке не так уж много интересного. Только кажется - мол, 17 гб, а на деле такое себе. У разработчиков coreboot давно есть куда более полезные документы и исходники. Те же доки по ME, TXE, BootGuard - все это давно есть.

А инфа у меня оттуда, что я сам разработчик coreboot.))

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

76. "Утечка 20ГБ внутренней технической документации и исходных т..."  +/
Сообщение от Аноним (73), 07-Авг-20, 13:01 
Разве проблема не в доках именно на процы и чипсеты?
Если я не ошибаюсь то это и есть причина того что поддерживаемых корбутом плат едва ли несколько десятков наберется.
Ответить | Правка | Наверх | Cообщить модератору

85. "Утечка 20ГБ внутренней технической документации и исходных т..."  +5 +/
Сообщение от Аноним (85), 07-Авг-20, 13:32 
Ну у нас, в принципе, много доков на процы и чипсеты, хотя это не всё. Например, я не знаю никого без NDA, у кого бы был слитый SA BIOS Spec (System Agent BIOS Specification), а без него не напишешь инициализацию интегрированной GPU например. В этом плане часто утекшие исходники какого-нибудь Insyde или AMI BIOS бывают полезнее, чем доки, можно просто оттуда списать (там обычно ещё и с комментариями). Вот недавно еще Intel FSP утёк.

(Это, кстати, вторая крупная утечка доков Intel за этот год, только о первой никто не знает. Там ещё AMD слили. Доки передаются из рук в руки.)

А самая главная проблема это конечно даже не доки и исходники, а человеческий ресурс. Было бы больше энтузиастов, кто бы сидел и портировал свои платы, было бы намного больше плат поддерживаемых, даже без всяких утечек.

Ответить | Правка | Наверх | Cообщить модератору

151. "Утечка 20ГБ внутренней технической документации и исходных т..."  +/
Сообщение от Аноним (150), 07-Авг-20, 19:28 
Понимаешь в чём проблема .... у людей обычно 1 компьютер. И им нужно им пользоваться. А для портирования плат нужно 2 компьютера. То есть люди должны взять и выложить бабло ещё за один комп, только для того чтобы ничего больше не делать, кроме как постоянно ним корпеть до его устаревания, а потом выкинуть.

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

Ответить | Правка | Наверх | Cообщить модератору

155. "Утечка 20ГБ внутренней технической документации и исходных т..."  +1 +/
Сообщение от Аноним (-), 07-Авг-20, 19:41 
Не особо эффективно. Во первых, так железо могут урыть и наповал. Во вторых, локально передернуть питание или ресетнуть все же быстрее, эффективнее и результативнее.

Там народ юзает например разветвитель на 2 чипа, нормальный и экспериментальный. Ну и для вот именно вашего компа - чего надо? Поднять точно такой же для вас, но за свой счет? Хм...

p.s. а таки одна знакомая перелила coreboot тупо с "малинки" которая тоже за комп сойдет, с которого вполне можно SPI чип прошить и еще чего по мелочи.

Ответить | Правка | Наверх | Cообщить модератору

156. "Утечка 20ГБ внутренней технической документации и исходных т..."  +/
Сообщение от Аноним (-), 07-Авг-20, 19:42 
ЗЫ интересно, а тут никто по душам с батареями ноутов не разговаривал по i2c?
Ответить | Правка | Наверх | Cообщить модератору

170. "Утечка 20ГБ внутренней технической документации и исходных т..."  +/
Сообщение от Аноним (170), 07-Авг-20, 22:58 
Ну без физического доступа сложно очень будет что-то портировать. Да и потом, кто-то же всё равно должен будет за это платить.
Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору

219. "Утечка 20ГБ внутренней технической документации и исходных т..."  +/
Сообщение от Аноним (219), 16-Авг-20, 15:21 
Скинь ссылки, доки и сорцы других утечек.
Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

147. "Утечка 20ГБ внутренней технической документации и исходных т..."  +/
Сообщение от Супернуб (?), 07-Авг-20, 19:06 
Когда будет прошивка с флешки/диска или каким другим "софтовым" способом?
А то с программатором не каждый справиться может - думаю, что на порядок меньше, чем желающих его поставить.

ЗЫ. На какой-то "ленивец" 400й серии (430?) патченый Бивис с вырезанным "белым списком" и полным мень ставится через использование уязвимости в том самом Бивосе: в начале делается откат до уязвимой версии, а потом заливается патченый (утилитка бродит по инету. И она таки работает). При том, что официально это можно сделать якобы только через програматор.

Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

175. "Утечка 20ГБ внутренней технической документации и исходных т..."  +7 +/
Сообщение от Аноним (175), 08-Авг-20, 00:17 
Возможность софтварной прошивки зависит от биоса. Я не разбираюсь в AMD, но могу рассказать как это работает в Intel. Это как раз я и написал ту статью про прошивку x230/t430/t530 через уязвимость, а потом ребята по ней сделали 1vyrain. Кстати уже есть официальная дока: https://doc.coreboot.org/mainboard/lenovo/ivb_internal_flash...

Итак, сейчас будет небольшая лекция.

Во-первых существует несколько регистров:

1. Регистры PR0-PR5 (SPIBAR+0x74), в них задается защищаемая область SPI чипа, плюс есть бит WP, если он 1, то в указанную область нельзя писать.

2. Рядом (SPIBAR+0x04) есть регистр HSFS, в нем есть бит FLOCKDN, если он 1, то снять его может только reset хоста, а ещё когда он 1, то нельзя писать в регистры PR0-PR5.

3. Регистр BIOS_CNTL (LPC Interface Bridge, в адресном пространстве PCI), в нем есть биты BIOSWE, SMM_BWP и BLE.

BIOSWE всегда R/W, он контролирует можно ли писать в биос. То есть перед записью в любом случае его нужно проставить в 1, например flashrom делает это сам автоматически.
Если SMM_BWP=1, то писать в биос можно из SMM. После установки в 1 изменить нельзя.
Если BLE=1, то установка BIOSWE в 1 вызовет SMI (прерывание SMM). После установки в 1 изменить нельзя.

Из информации выше должно быть понятно, что для нормальной записи нужно либо отсутствие проставленных PRx (либо бита WP в них), либо непроставленный бит FLOCKDN, чтобы можно было просто обнулить регистры PRx, при этом крайне желательно иметь выключенные SMM_BWP/BLE, иначе нужен ещё и SMM эксплоит, поскольку писать можно будет только из SMM.

Способ записи на 30-й серии thinkpad основывается как раз на том, что в старых версиях биоса отключен SMM_BWP, плюс из-за незащищенного UEFI bootscript можно перезаписать этот самый bootscript, и подменить значения регистров, которые будут писаться из этого скрипта при восстановлении из S3, например снять бит FLOCKDN регистра HSFS.

Ещё как пример у меня есть ноут Samsung, там PRx вообще не проставлены, SMM_BWP тоже 0, и биос можно спокойно полностью перезаписать из-под линукса.

Но это ещё не все, самое веселое только начинается.

Во-вторых, есть биты доступа во флеш дескрипторе (FD). К разделу, в котором лежит собственно сам биос, это не относится, но там задаются права на чтение/запись к разделу ME и самому флеш дескриптору.

При этом доступ к флеш дескриптору можно переопределить (это фича железа), замкнув пин HDA_SDO на единицу, либо в случае старых платформ, если я не ошибаюсь (надо сверяться с доками), GPIO33 на землю при включении. В этом случае до следующего резета заданные права доступа к FD будут игнорироваться и в него можно будет писать. На некоторых ноутах, кстати (HP вроде), есть даже какой-то хоткей, по-видимому реализуемый через EC, который это делает. Это называется пинмод. Тут нужно смотреть схематику и иметь более-менее прямые руки, чтобы чего-нибудь лишнего не замкнуть.

Если вендор не сделал fd read-only либо не защитил его регистрами PRx либо вы сделали пинмод, короче если можно в него писать, плюс можно писать куда-нибудь ещё, например в область ME (бывает, что она тоже R/W и ME работает в manufacturing mode, так в Apple раньше делали), либо в часть региона bios (часто защищают только bootblock, остальное можно писать, пример - thinkpad x220), либо есть любая другая открытая для записи область размером хотя бы несколько сотен килобайт, это открывает возможность для сложного, хрупкого, но реального хака.

Приведу пример с реальными данными с x220. Биос лежит в 0x00500000-0x007fffff. Через регистры PRx и бит FLOCKDN защищена область 0x00780000-0x007fffff, что означает что мы спокойно можем писать всё что угодно в 0x00500000-0x0077ffff. Что мы можем сделать:

a) собираем маленький образ coreboot с небольшим payload, например seabios, либо grub с минимумом модулей, который поместится в свободную для записи область. Главное заранее подумать о том, чтобы выбранный payload был способен потом загрузить вашу ОС.

b) пишем его в эту область.

c) патчим флеш дескриптор (через тот же ifdtool): переопределяем раздел bios как 0x00500000-0x0077ffff, 0x0077ffff это будет новый reset vector. Плюс добавляем новый раздел 0x00780000-0x007fffff, можно назвать его pd (platform data), это обязательно нужно для того, чтобы в будущем можно было в него писать. Если нет раздела, то и писать в эту область не получится.

d) прошиваем новый флеш дескриптор

e) выключаем компьютер. Именно выключаем, т.к. новый fd вступит в силу только с холодного старта.

f) Если делали пинмод, то надо будет снова. Включаем компьютер, у нас загружается наш маленький coreboot из нового раздела. Загружаемся в линукс, никакие PRx больше не стоят.

g) Снова патчим fd, чтобы bios занимал все доступное пространство 0x00500000-0x007fffff, либо просто берем оригинальный. Прошиваем новый fd.

h) Собираем нормальный coreboot и прошиваем уже куда надо, т.е. в 0x00500000-0x007fffff. Еще одно выключение-включение и готово.

Это довольно ненадежная (в том плане, что малейшая ошибка и вы получите кирпич, который надо будет восстанавливать программатором), но абсолютно реальная процедура, которую я проворачивал на макбуках, и даже скрипт для этого написал и доку https://review.coreboot.org/c/coreboot/+/38770, а один юзер с irc-канала #coreboot таким образом прошил свой x201.

---

Полагаю, я исчерпывающе ответил на вопрос "когда будет прошивка с флешки/диска или каким другим "софтовым" способом?" - это зависит не от нас.

Ответить | Правка | Наверх | Cообщить модератору

183. "Утечка 20ГБ внутренней технической документации и исходных т..."  +/
Сообщение от Аноним (183), 08-Авг-20, 11:53 
Ты хотел сказать LibreBOOT.

Coreboot прекрасно себя чувствует с закрытыми, проприетарными блобами от Intel.

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

189. "Утечка 20ГБ внутренней технической документации и исходных т..."  +/
Сообщение от Аноним (175), 08-Авг-20, 14:11 
libreboot это просто дистрибутив coreboot для тех платформ, для которых можно собрать его без блобов (в т.ч. без ME, даже обрезанного me_cleaner-ом). coreboot для этих же платформ точно так же можно собрать без блобов.
Ответить | Правка | Наверх | Cообщить модератору

191. "Утечка 20ГБ внутренней технической документации и исходных т..."  +/
Сообщение от Аноним (191), 08-Авг-20, 15:16 
Теперь число чипсетов Intel для которых можно собрать без блобов LibreBOOT увеличится.
Ответить | Правка | Наверх | Cообщить модератору

192. "Утечка 20ГБ внутренней технической документации и исходных т..."  +/
Сообщение от Аноним (85), 08-Авг-20, 15:19 
> Теперь число чипсетов Intel для которых можно собрать без блобов LibreBOOT увеличится.

Не увеличится, если только они не решат собирать libreboot для платформ, на которых можно применить me_cleaner. А если решат, то так давно можно было - для sandy и ivy bridge в coreboot давно есть опенсорсная инициализация памяти и графики. И эта утечка для того, что вы пишете, не очень полезна - утечка исходников FSP двухмесячной давности намного полезнее.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру