ARM уязвимы?

Spectre

эту нашел. Интересуют остальные

Meltdown

аналоги как интел ми в Интел и PSP в АМД?

TrustZone. Например https://habr.com/post/309618/

Точно неуязвимы к Spectre только процессоры без динамического предсказания переходов.
Точно неуязвимы к Meltdown только процессоры без out of order execution.
Официальный список уязвимых ARM: https://developer.arm.com/support/arm-security-updates/speculative-processor-...
Вот к примеру ARM Cortex-A53 по идеи без уязвимостей, так как он in-order execution. Но вот насчет переходов не уверен, на википедии сказано 4 KiB conditional branch predictor, 256-entry indirect branch predictor что явно на статический предсказатель переходов не тянет.
Я про внутренности ARM не очень хорошо знаю, но вроде как там кучу вещей можно включать/отключать. Как-то кеши надо включать чтоб работали, может и предсказатель можно отключить. Может вообще out of order можно отключить, надо спеки читать.

Если не ошибаюсь, то обычно есть 4kb кода самого первого загрузчика который проводит самую первую инициализацию минимальной перефирии(как-то инициализация оперативки), который вроде как нельзя не то что заменить, но и прочитать его невозможно(одна надежда что в 4kb ничего вредоносного не внести, и то что там действительно 4kb а не 512kb к примеру). Дальше идет уже вспомогательный загрузчик который обычно можно заменить, он нужен только для того чтоб можно было загрузить основной загрузчик с MicroSD, NAND, USB и т.д.
Для UEFI/DRM у ARM есть так называемая TrustZone, его обычно называют альтернативой Intel ME/PSP. Но это такой защищенный уровень, при чем в начале проц работает именно в этом защищенном режиме. Так что если твой код при старте находится в этом режиме, то можно считать что никакого левого кода в TrustZone нету, если нет то скорее все-го кто то уже в TrustZone прописался.

Если я где-то не прав, прошу указать. Самому интересны ARM-ы, да вот времени с ними поразбераться пока на них нет.

Meltdown

Только свежайшее ядро Cortex-A75.

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

что за эмка?

Точно неуязвимы к Meltdown только процессоры без out of order execution

Meltdown в списке ARM-а под номером 3. И только Cortex-A75 ему подвержен.
Уязвимость «3a» позволяет читать привелигированные регистры процессора. Ничего особо ценного оттуда не вытащить.

А почему в твоём понимании
Закладки производителя == Уязвимость
Это же разные вещи совсем.

что за эмка?

Микроконтроллерное ядро Cortex-Mx.
У Allwinner-ов, например, есть ядро OpenRISC - AR100. Но это всё не значит, что там везде работают закладки.

это разные - но иногда к закладке можно получить доступ через уязвимость. В общем решил узначть что с армами не так. Я так понял еще с видеокарточками на них проблемы?

выбирал между старой материнки, новой с интел ми и уефай, амдошной с псп и снятой с производства без псп)

Я так понял еще с видеокарточками на них проблемы?

Я знаю только про двух производителей видеокарт с opensource драйверами, это Intel и AMD. Но я не слышал об ARM с встройкой от Intel иди AMD. Есть конечно реверснутые драйверы для некоторого количества наименований встроек которые пихают в ARM, но это надо разбираться насколько он хорош и что поддерживает.

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

меня закрытые драйвера устраивают на арме.

Так о чём тогда разговор? В драйвера прекрасно можно встроить закладки.
С другой стороны, если тебе не нужены 2D ускорители и 3D, то можно пользоваться открытыми драйверами, работающими через фреймбуфер.

А вообще, с твоим уровнем подготовки NSA тебя обязательно поимеет.

проприетарный драйвер от производителя должен выдавать качественней картинку чем свободный?

оно кого угодно может разоблачить.

Что значит «встроить»? Учитывая любовь проприетарных компаний поднимать 100500 сервисов на всех интерфейсах можно считать там не одна и не две «уязвимости» прямо сейчас и факты их наличия подтверждались неоднократно.

проприетарный драйвер от производителя должен выдавать качественней картинку чем свободный?

От производителя должен быть много быстрее. К тому же, открытые драйвера не умеют 3D.

можно считать там не одна и не две «уязвимости» прямо сейчас ...

Не каждая уязвимость является закладкой. Во всяком случае, я считаю, что это не одно и то же.

Вполне возможно и так, только они будут известны спецслужбам за годы до исправления. Как хакеры найдут так и исправят. Через полгодика. Что это, если не умысел?

Если так сильно боишься аппаратных уязвимостей, возьми ПЛИС и прошей собственной прошивкой.

оно кого угодно может разоблачить.

Далеко не кого угодно. Иначе давно бы всех преступников, шпионов и террористов поймали. Вообще, не нужно переоценивать возможности спецслужб. Это так же глупо, как и не дооценивать их.

проприетарный драйвер от производителя должен выдавать качественней картинку чем свободный?

От производителя должен быть много быстрее.

Должно быть всё ровно наоборот. Но по факту имеем то, что имеем, из-за того, что производители скрывают программный интерфейс своих устройств от общественности. А на качество картинки может повлиять монитор, метод сжатия, но никак не драйвер.

Зато Америка ЕМНИП уже замечена в шпионаже за Германией, вот вам и переоценивать. Просто тузов в рукаве терять не спешат. Так и живём.

Зато Америка ЕМНИП уже замечена в шпионаже за Германией, вот вам и переоценивать.

Я же не сказал, что они вообще ничего не могут. Но далеко не всесильны. Вон и педофилов разоблачили, благодаря уязвимости в торе флэш-плеере, которым разработчики тора настоятельно рекомендовали не пользоваться. И что? Это они такие умные? Я думаю, что это педофилы дураки. Так же, скорее всего, и с Германией было. Не придавали значения безопасности, хотя известно, что весь трафик через ту же Англию прослушивается США. Да и вообще любую радио и спутниковую связь можно прослушать. Т. е. надо пользоваться надёжными шифрованными каналами, по возможности проводными. Службы радио-электронной безопасности должны этим заниматься. А политики должны их слушать. Я не удивлюсь, если узнаю, что они и Медведева слушают, что он там по своему айфону говорит. Но это Медведев дурак, а не они такие умные. В конечном итоге возможность почти любого взлома является следствием чьей-то ошибки или легкомысленности.

spectre/meltdown экспулатируются только в очень конкретных случаях. вероятность какого-то попадоса на однопользовательском устройстве около 0. На многопользовательском без анализа сложно что-то сказать. Но повысить привилегии через это непосредственно не получится. Вытащить какую-то информацию можно, если карта ляжет идеально. Всегда проще использовать косяки от вендора прошивки.

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

да

меня закрытые драйвера устраивают на арме.

Если я не ошибаюсь то с драйверами по крайней мере на мали выглядит примерно так:

1. Есть список фич мали(поддержка OpenGL, OpenCV, OpenVG, аппаратное кодирование/декодирование), и каждая такая фича стоит денег.
   
2. В зависимости насколько тот или иной производитель телефона щедр и купит нужные фичи для пользователей с такими опциями и будет скомпилирован бинарь чисто под их нужды под сборку ядра что будет на телефоне. И вроде как универсального драйвера для них нет.
   
3. Как только выходит новая версия Android-а и бинарь от mali теряет совместимость, то тут нельзя просто попросить от mali новый бинарь под новую версию, надо именно заплатить за это(и за нужные фичи естественно также). А это ненужные расходы и обычно производители забивают на это и не выпускают новую сборку Android под их смартофоны.
   
4. Если ты хочешь собрать свою сборку ядра под смартофон, то выбор только из тех версий для которых есть бинарь для видеокарты.

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

Есть список фич мали(поддержка OpenGL, OpenCV, OpenVG, аппаратное кодирование/декодирование), и каждая такая фича стоит денег.

К аппаратному кодированию/декодированию Mali вообще не имеет никакого отношения.

Поправьте меня если я не прав, но по тому что я читал и вижу все выглядит именно так.

Ты вообще «не в теме». Не совсем понятно, зачем ты это желаешь всем продемонстрировать.
Как обстояли дела с open source драйверами GPU год назад можно прочесть в этой статье блога:
«The state of open source accelerated graphics on ARM devices»

Мало что существенно изменилось с тех пор. Кроме того, что над open source драйверами LIMA и Panfrost начали более активно работать, вроде бы.

Ты не прав, ARM Ltd. разрабатывает кучу разных IP блоков которые они называют Mali. Напрмер VPU у них идут под брендами Mali-Vxxx, контроллеры дисплея Mali-Dxx и DPxxx, Mali-Cxx - контроллеры камеры. И только T и G серии у них отвечают за 3d графику. Другое дело что каждый уважающий себя производитель SoC считает своим долгом разработать свой проприетарный VPU и IPU, потому все привыкли ассоциировать mali исключительно с 3d ускорителями.

Ты вообще «не в теме». Не совсем понятно, зачем ты это желаешь всем продемонстрировать.

Ну так я про это прямо и написал. Периодически смотрю что там в ARM мире творится, но вот целостной картины пока не очень складывается. Вот и прошу поправить если я что-то не правильно понял.

Ты не прав, ARM Ltd. разрабатывает кучу разных IP блоков которые они называют Mali. Напрмер VPU у них идут под брендами Mali-Vxxx, к

Да, здесь я чуток прогнал. VPU у них тоже под брендом Mali выпускают. Но суть моего сообщения, думаю, ясна.
Кстати, VPU от ARM Holdings, насколько я знаю, почти никто и не применяет.

Другое дело что каждый уважающий себя производитель SoC считает своим долгом разработать свой проприетарный VPU и IPU

Часто покупают готовые IP у третьих сторон.

потому все привыкли ассоциировать mali исключительно с 3d ускорителями.

Это есть. С этим я маленько лажанулся.

Про мали сушь написана

Модули ядра идут в исходниках так что портировать на новые ядра возможность есть.

Дрова на мали арм выкладывает у себя на сайте

В трастзону прописаться очень непросто, бинарник её кода подписан, как правило. Многие SoC'и также даже bl0/uboot требуют подписанных (хотя с uboot подписывалку для uboot обычно дают)

Насколько помню, там крошечный кернелспейс в исходниках и заголовочные файлы и библиотеки для взаимодействия с ним. Всё остальное там в юзерспейсе, и чтобы его сделать, надо отдельно заплатит ARM Holding'су

вроде как они дают скачать всё. Проблема в том, что под фактическое использование это надо пилить, а распространять модифицированный результат нельзя. Еще проболема в том, что оно сделано под совсем древние ядра, то есть никакой поддержки DRM = тормоза и костыли, так как userspace менять нельзя. То есть хочешь сделать что-то хорошее - плати. Под более новое железо дрова нормальные, но это железо днём с огнём не сыщешь.

https://developer.arm.com/products/software/mali-drivers

возьми ПЛИС и прошей собственной прошивкой

ПЛИС не катит - потому что для синтеза прошивки для любых объёмных ПЛИС нужен закрытый несвободный софт, который в теории может скрытно добавить какую-нибудь бяку к твоему процессору. есть проект http://www.clifford.at/icestorm/ но там то ли 8 то ли 16 тысяч вентилей в поддерживаемой ПЛИС максимального объёма - соответственно, большой серьёзный процессор при помощи опенсорса в ПЛИС пока не получишь

возьми ПЛИС и прошей собственной прошивкой

ПЛИС не катит - потому что для синтеза прошивки для любых объёмных ПЛИС нужен закрытый несвободный софт, который в теории может скрытно добавить какую-нибудь бяку к твоему процессору.

Риск есть всегда. Даже если иметь дело с полностью свободным и открытым компилятором, т. к. этот компилятор собирался с использованием более старой версии компилятора. И если хотя бы одна из версий дцать лет назад была закрытой, там могли быть добавлены закладки, которые теоретически могут оставаться и по сей день. Об этом говорил ещё Кен Томпсон в 1983 году («Лекции лауреатов премии Тьюринга за первые двадцать лет 1966 — 1985», Москва, изд. «Мир», 1993, «Размышления о том, можно ли полагаться на доверие», перевод Н. Б. Дерябин, ст. 203 — 209). Процитирую отрывок из перевода его лекции со ссылкой на собственный камент (других текстовых ссылок на русском я в своё время в Сети не нашёл):

Кен Томпсон, Лекции лауреатов премии Тьюринга, лекция за 1983 год

На рис. 2.1 представлен фрагмент программы компилятора Си, в котором интерпретируются управляющие последовательности символов. Это удивительный фрагмент. Он «знает» полностью переносимым образом, какой код символа компилируется для новой строки в любой кодировке символов. Этот элемент знания позволяет ему перекомпилировать себя, увековечив таким образом знание.

Предположим, мы хотим изменить компилятор Си, чтобы включить управляющую последовательность «\v» для представления символа вертикальной табуляции. Расширение фрагмента 2.1 очевидно и представлено на рис. 2.2. Затем мы заново компилируем компилятор Си, но получаем сообщение об ошибке. Ясно, что поскольку компилятор Си в готовом виде ничего не знает о «\v», исходная программа не является правильной программой на языке Си. Заглянув в таблицу кодировки символов ASCII, мы находим, что код вертикальной табуляции - десятичное 11. Мы изменяем нашу исходную программу , как показано на рис. 2.3. Теперь старый компилятор компилирует новый исходный текст без ошибок. Мы устанавливаем полученную готовую программу как новую официальную версию компилятора Си и теперь можем написать мобильную версию, как это сделано на рис. 2.2.

Рис. 2.1:

c = next();
if(c != '\\')
  return(c);
c = next();
if(c == '\\')
  return(c);
if(c == 'n')
  return('\n');

Рис. 2.2:

c = next();
if(c != '\\')
  return(c);
c = next();
if(c == '\\')
  return(c);
if(c == 'n')
  return('\n');
if(c == 'v')
  return '\v';

Рис. 2.3:

c = next();
if(c != '\\')
  return(c);
c = next();
if(c == '\\')
  return(c);
if(c == 'n')
  return('\n');
if(c == 'v')
  return 11;

Это глубокая идея. В моём понимании она близка к понятию «обучающейся» программы. Вы просто сообщаете новое знание один раз, а затем можете использовать определение, ссылающееся на само себя.

Далее описывается 3-й этап, на котором такая открытая «самообучающаяся» программа, ссылающаяся на саму себя, воспроизводит жучок:

Кен Томпсон, Лекции лауреатов премии Тьюринга, лекция за 1983 год, продолжение

Этап III

Снова компилятор Си. На рис. 3.1 показан фрагмент компилятора Си, занимающий высокий уровень в его структуре. Подпрограмма «compile» вызывается для компиляции каждой следующей строки исходного текста. На рис. 3.2 показана модификация компилятора, которая преднамеренно неправильно компилирует исходную программу, когда в ней встречается заданный образец. Когда такое делается непреднамеренно, это называется ошибкой компилятора, или «жучком» («bug» — моё дополнение). Так как это сделано преднамеренно, то говорят, что мы имеем дело с «троянским конём».

Действительный «жучок», который я встроил бы в компилятор, распознавал бы исходный текст команды login (вход в систему UNIX). Взамен подставлялся бы такой исходный текст, чтобы команда login принимала как правильный заранее известный пароль (в зашифрованном или обычном виде). Таким образом, если бы такой компилятор был установлен в готовом (двоичном) виде и был использован для компиляции команды login, я мог бы войти в такую систему, как и любой другой пользователь.

Рис. 3.1:

compile(s)
char* s;
{
  ...
}

Рис. 3.2:

compile(s)
char* s;
{
  if(match(s, "pattern")) {
    compile("bug");
    return;
  }
  ...
}

Рис. 3.3:

compile(s)
char* s;
{
  if(match(s, "образец 1")) {
    compile("жучок 1");
    return;
  }
  if(match(s, "образец 2")) {
    compile("жучок 2");
    return;
  }
  ...
}

Такая наглая вставка в программе не долго оставалась бы незамеченной. Даже при случайном внимательном просмотре исходного текста компилятора Си она вызвала бы подозрение.

Заключительный шаг представлен на рис. 3.3. Он заключается в простом добавлении ещё одного «троянского коня» к уже существующему. Второй образец настроен на сам компилятор Си. Заменяющим текстом служит самовоспроизводящаяся программа (см. этап I), которая вставляет обоих «троянских коней» в компилятор. Потребуется также фаза обучения, как в примере из этапа II. Сначала мы компилируем модифицированный исходный текст компилятором Си и получаем готовую программу с «жучком». Затем устанавливаем эту готовую программу как официальный компилятор Си. Теперь можно удалить жучки из исходного текста компилятора, а новый компилятор будет воспроизводить жучки при каждой перекомпиляции. Команда login, естественно, будет оставаться с «жучком» без всякого следа в каких-либо исходных текстах.

МОРАЛЬ

Мораль ясна. Нельзя доверять программе, которую вы не писали полностью сами (особенно если эта программа пришла из компании, нанимающей таких людей, как я). Сколько бы вы не исследовали и не верифицировали исходный текст — это не защитит вас от троянской программы. Для демонстрации атаки такого рода я выбрал компилятор Си. Я мог бы выбрать любую программу, обрабатывающую другие программы — ассемблер, загрузчик или даже микропрограмму, зашитую в аппаратуру. Чем ниже уровень программы, тем труднее и труднее обнаруживать подобные «жучки». Мастерски встроенный «жучок» в микропрограмме будет почти невозможно обнаружить.

Как в воду глядел! Привет этим вашим CVE-2017-5703 и прочим мелтдаунам из 83 года! :-)

Как в воду глядел! Привет этим вашим CVE-2017-5703 и прочим мелтдаунам из 83 года! :-)

почему сразу не из древней греции? ведь троянский конь они придумали, никто никогда до такого бы не додумалсяб, а они смогли, и все досихпор пользуются!

--

описанное тобой очевидно Любому человеку поработавшему на компьютере Час
очевидные знания не могут быть приписаны «комуто»
придаешь важности и популизма своим постам ссылаясь на очевидную банальшину «датированную годом»- нет ты выставляешь себя дураком

если ты «гумуниторий» то да все в порядке, продолжай этим аниматься продовая свою «напыщенную ложь»

если ты «гумуниторий» то да все в порядке, продолжай этим аниматься продовая свою «напыщенную ложь»

Все претензии Томпсону, который «гумуниторий» и «продоёт свою напыщенную ложь», а не ко мне.

очень интересно! получается нужно переходить на KolibriOS - https://kolibrios.org/ru/index - там всё на ассемблере написано, и более-менее можно пользоваться: графический интерфейс есть и прекрасно работает

там всё на ассемблере написано

Исходник самого fasm-а можно скомпилить только fasm-ом, который надо качнуть с сайта. Где начало? Те же яйца, только в профиль?

исходники fasm весят где-то полмегабайта, и - по сравнению с исходниками gcc - их реально проверить одному человеку, да и свой собственный ассемблер для его сборки тоже реально создать

очень интересно! получается нужно переходить на KolibriOS - https://kolibrios.org/ru/index - там всё на ассемблере написано

Ну, нужно-не нужно — это тебе лучше меня modus_exciter может рассказать, т. к. юзал её, в отличие от меня. А касательно ассемблера, ещё раз процитирую Томпсона:

Для демонстрации атаки такого рода я выбрал компилятор Си. Я мог бы выбрать любую программу, обрабатывающую другие программы — ассемблер, загрузчик или даже микропрограмму, зашитую в аппаратуру. Чем ниже уровень программы, тем труднее и труднее обнаруживать подобные «жучки».

Так что абсолютных гарантий нет нигде. Только если сам напишешь всё от корки до корки в машинных кодах. Ну или только ассемблер в машинных кодах напишешь, а на нём уже всё остальное. Это тоже не защитит тебя от ошибок и связанных с ними уязвимостей, но, по крайней мере, ты можешь быть уверен, что намеренно оставленных троянов там нет (если, конечно, никто их в твоё отсутствие туда не подсунул). :-)

исходники fasm весят где-то полмегабайта,

Это примерно пол миллиона байт. Команды у Intel разной длины, но если от балды за средний размер принять 4 байта, то получаем порядка 120 тыс. команд. Не так уж и мало.

и - по сравнению с исходниками gcc - их реально проверить одному человеку, да и свой собственный ассемблер для его сборки тоже реально создать

Вот когда всё проверишь либо напишешь свой ассемблер на машинных командах и на нём всё пересоберёшь, тогда можешь быть уверен в том, что кроме ошибок (возможно, не менее опасных, чем трояны), в коде никаких других бяк не имеется. :-)

Заодно не забудь пересобрать линкер, — он тоже может подсунуть бяку.

Если так сильно боишься аппаратных уязвимостей, возьми ПЛИС и прошей собственной прошивкой.

Ждем тред «ПЛИС уязвимы?».

И заодно libc , т.к. [f]write пишет итоговый бинарник на диск. И заодно хотя бы проверит не серанул ли системный вызов, к-рый сбрасывает буфер на диск. :)

Ну, если мы говорим об отдельно взятой kolibrios, полностью написанной на ассемблере с нуля, без подключения сторонних либ, то это, имхо, лишнее. Достаточно быть уверенным в используемом ассемблере и линкере, ну и в исходниках самой ОС, разумеется. :-)