LINUX.ORG.RU
ФорумTalks

Утечка данных через кольцевую шину CPU Intel

 


0

1

Пацаны, к нам снова традиционный дуршлаг с подогревом от Интел подъехал:

https://www.opennet.ru/opennews/art.shtml?num=54717

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

Ай, хорошо!

★★

Последнее исправление: wandrien (всего исправлений: 1)

Никогда такого не было, и вот опять

Хорошо что у меня штеудов нет в хозяйстве. Только амд и кортексы.

cocucka ★★★★☆
()

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

Это мощно. Обычно в других уязвимостях скорость передачи данных составляет несколько байт в секунду.

X512 ★★★★★
()

Как бы не оказалось, что в целях безопасности придётся через несколько лет вернуться к производительности однопотока уровня Core 2 Duo.

Дыры утечек по сторонним каналам всё круче и круче. Вангую, это только начало…

wandrien ★★
() автор топика

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

BceM_IIpuBeT ★★☆☆☆
()
Ответ на: комментарий от BceM_IIpuBeT

В проприетарщине уязвимостей меньше.

Почти все производительные процессоры — это проприетарщина.

X512 ★★★★★
()
Ответ на: комментарий от wandrien

Давно пора. Штеуд – оверпраснутое говно.

cocucka ★★★★☆
()

Ждём скачка цен на акции AMD и на серверные EPYCи.

gag ★★★★★
()

Это позволяет нагибать копирастов с их защитами?

praseodim ★★★★★
()

Утечка данных через кольцевую шину

так вулканизацию сделай

Shulman
()

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

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

deep-purple ★★★★★
()
Последнее исправление: deep-purple (всего исправлений: 1)
Ответ на: комментарий от deep-purple

И будет она медленная как топор.

В современных GPU вообще AI запилен. Вот где простор… только пока непонятно, для чего.

wandrien ★★
() автор топика
Ответ на: комментарий от wandrien

ты не дал дописать к тому сообщению:

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

-------

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

deep-purple ★★★★★
()
Последнее исправление: deep-purple (всего исправлений: 2)
Ответ на: комментарий от deep-purple

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

Ну и как бы они это сделали?

нет, она не будет медленной

Там утечки на побочных эффектах, а побочные эффекты — суть оптимизации кода. Оптимизированный код начинает выполняться быстрее. То есть для полного закрытия дыры нужен максимально дубовый проц, который ничего не оптимизирует.

И наверное к этому и придём.

wandrien ★★
() автор топика
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от wandrien

Ну и как бы они это сделали?

Поищи — я тред создавал и там это все обсуждали.

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

А я сейчас выше про что изначально сказал?

И наверное к этому и придём

К сожалению, мы от этого ушли настолько далеко, что возвращаться придется еще очень и очень долго.

deep-purple ★★★★★
()

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

seiken ★★★★★
()
Ответ на: комментарий от seiken

Атака на данные труднореализуема, а вот канал передачи данных — легко. Как я понял.

wandrien ★★
() автор топика
Ответ на: комментарий от BceM_IIpuBeT

А есть непроприетарные процессоры?

Reset ★★★★★
()

Боюсь что у АМД таких уязвимостей не нашли только лишь потому что не искали как следует.

DawnCaster ★★
()

Почему вы удивляетесь?

Крис Касперски ещё 100 лет назад говорил и писал, что в процах Intel 100500 ошибок. Может и про AMD писал, не помню просто. Короче везде дыры. В компиляторах(!) ошибки, начиная с ASMа. Их(ошибок) ещё 50 минимум есть.
Эльбрусовцы писали, что во всех процах куча мусора и ошибок, когда реализацию x86 делали...
Моё экспертное заключение диванного аналитика, что это намеренная обфускация, с целью спрятать лазейки для себя.

xwicked ★★☆
()
Последнее исправление: xwicked (всего исправлений: 3)
Ответ на: комментарий от X512

В данном случае канал не утечки, а передачи.

greenman ★★★★★
()
Ответ на: комментарий от TooPar

В рыжих давно. Нейронка ветвления предсказывает

Точно. Теперь вспомнил, что читал где-то об этом.

Отстаю от прогресса.

wandrien ★★
() автор топика
Ответ на: комментарий от deep-purple

К сожалению, мы от этого ушли настолько далеко, что возвращаться придется еще очень и очень долго.

Чем дальше продвинутся исследования, тем всё более слабозаметные явления можно будет анализировать.

Как бы потом не оказалось, что единственный способ устранить утечку — запускать каждую критичную подсистему или процесс на отдельном ядре с отдельным ОЗУ.

wandrien ★★
() автор топика
Ответ на: комментарий от wandrien

запускать каждую критичную подсистему или процесс на отдельном ядре с отдельным ОЗУ

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

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

От чего ушли к тому и придём. Отдельно аппаратный drm-кодек, отдельно универсальный AES, отдельно переходная плата со сменными модулями подсчёта хэшей.
Все эти смузи-виртуализации и 100500 песочниц в namespace'ах от лукавого.

Suigintou ★★★★★
()
Ответ на: комментарий от Suigintou

Отдельно аппаратный drm-кодек, отдельно универсальный AES, отдельно переходная плата со сменными модулями подсчёта хэшей.

Этого не достаточно.

Там был пример атаки: чтение суперблока ФС, чтение inode файла /etc/shadow, поиск страницы файла в блочном кэше и получение содержимого. И всё по сторонним каналам связи.

Так что только полностью отдельные устройства со связью через сеть и рандомизированными (независимым источником энтропии) задержками ответа, делающими невозможной тайминг-атаку.

wandrien ★★
() автор топика
Последнее исправление: wandrien (всего исправлений: 2)
Ответ на: комментарий от wandrien

рандомизированными (независимым источником энтропии) задержками ответа, делающими невозможной тайминг-атаку

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

X512 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.