LINUX.ORG.RU
ФорумTalks

Microsoft и Google сообщили об очередной уязвимости в процессорах Intel

 , , ,


0

1

https://dtf.ru/20013-microsoft-i-google-soobshchili-ob-ocherednoy-uyazvimosti...

Поддерживаю следующий комментарий про голубых:

Теперь Интел будут процессорами-инвалидами. Там заплатка, там гипс, еще где-то повязка...

От это наговнякали хардварного говнокода.
Опять юзверя виноваты, орали - давай, давай, гыгахертцы!! :-)

Deleted
()

Самое время вспомнить про столь нелюбимых веб макак и осозать что остальные от них отличаются не столь сильно

NextGenenration ★★
()

А мне пофиг.

Deleted
()

Кажется в ядре линукс 4.1(чёто там) появилась функция выделенного пространства, типа как раз заплатка для бреши интела, даже воспользовавшись спекулятивным исполнением. пространство будет недоступно.

cheetah111v
()

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

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

Такое впечатление, что о этих уязвимостях гугл и прочие корпорации

об всех опуликованных в этом году уязвимостях знали студенты первых курсов десять лет назад, и воспринималось это как «фича», все пофик было

гугла сложно не заметить, вот и стало всем не пофик

все эти уязвимости эквивалентны «гугл пиарится»

missxu
()

А как они их фиксят в микрокоде-то? Тупо спекулятивное выполнение отрубают?

Deleted
()
Ответ на: комментарий от bbk123

Почему-то не видать этого для AMD. И это очень странно.

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

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

Не распарсил, что ты имел в виду.

Вообще, в конечном счёте получается, что любые команды, обращающиеся в RAM, нельзя исполнять спекулятивно. Теоретически, любые такие команды могут разгласить информацию через тайминги.

Остаётся безопасной для спекулятивного выполнения только всякая математика вида регистр/регистр или регистр/imm. Хреново так-то.

Deleted
()

Может пора признать, что такие сложные системы не верифицируемы. Просто считать всё уязвимым по-умолчанию, вырезать «мастурбейтинг манкис» имитацию безопасности отовсюду и вынести её в минимальный верифицируемый(ой ли?) гипервизор.

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

Просто все процессоры — проприетарные.

Тысячи глаз смотрят куда угодно, но редко на проблемы. Сколько тут человек найдётся, которые проверяли статическим анализатором хотя-бы простые sh скрипты?

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

Может пора признать, что такие сложные системы не верифицируемы.

Давно пора.

вырезать «мастурбейтинг манкис» имитацию безопасности отовсюду

Типа какой? At-rest и in-flight шифрования? Изоляции процессов? Кто тебе звук смешивать будет? Или виртуализовано будет все железо?

Чем больше я думаю про твою идею, тем больше она скатывается к

минимальный(ой ли?) верифицируемый(ой ли?) гипервизор.

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

Сколько тут человек найдётся, которые проверяли статическим анализатором хотя-бы простые sh скрипты?

А что, возможно писать многострочники на bash/sh без анализатора? Там же динамит на динамите.

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

А что, возможно писать многострочники на bash/sh без анализатора?

Для этого достаточно чтобы автор не слышал об этом и|или у него на машине всё работало. Вот к примеру в теме об уязвимости http://www.opennet.ru/opennews/art.shtml?num=48601 говорится о https://imgur.com/wsSXEz0

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

Может пора признать, что такие сложные системы не верифицируемы. Просто считать всё уязвимым по-умолчанию, вырезать «мастурбейтинг манкис» имитацию безопасности отовсюду и вынести её в минимальный верифицируемый(ой ли?) гипервизор.

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

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

Deleted
()

Теперь Интел будут процессорами-инвалидами. Там заплатка, там гипс, еще где-то повязка...

Они такие давно, со времён первопней.

Но проблема не том, что камни от Штеуда дырявы, а в том, что альтернатив нет.

Deleted
()
Ответ на: комментарий от t184256

После той статьи мне стало интересно проверить в какой-нибудь установленной системе скрипты. Только пока не нашёл время на это.

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

single thread performance

Мне казалось, что софт уже оптимизируют под мультипоток. Ну или ты любитель поиграть в танки.

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

Не все же задачи параллелятся

Deleted
()
Ответ на: комментарий от qula

Что дооптимизируют? Я не знаю процент софта, который умеет только в однопоток, но игры прекрасно себя чувствуют на райзенах (только не надо говорить, что на интеле (который скорее всего совсем в другой ценовой категории) фпсов больше).

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

лет 10 как оптимизируют, а воз и ныне там. мне, как автору многопоточного софта, i9 или даже Xeon Phi пригодился бы, только вот для еще 90% юзеров твой AMD, будь у него хоть 100 ядер, будет медленнее скромного 35 ваттника от Intel или копеечного Intel Pentium Gold.

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

Это так не работает. Скорость одного потока является бутылочным горлышком даже в многопотоке. Потому и получается, что «фпсов больше».

qula
()
Ответ на: комментарий от ozz_is_here

Нет конечно. Дырявые то все существующие на рынке x86.

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

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

Верить, что софт можно бесконечно улучшать под многопоток можно только когда незнаком с тем, как софт работает.

Ну и второй аспект: имея одно быстрое ядро, можно не долго заморачиваясь выпустить камень с 2, 4, 8... ядрами, и т.п.

А вот имея хоть 100-ядерную сборку из медленного говна... ребёнка за 1 месяц 9 женщин не родят тебе, короче.

Deleted
()

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

barberry ★★
()

Интересно... У меня в последнее время вентилятор на ноутбуке шумит сильнее, чем раньше, реже выключается. Ноутбук чистый, термопаста свежая. Может быть, конечно, меня глючит, но есть подозрение, что виноваты патчи, закрывающие уязвимости.

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

переделывать свои камни Интель не спешит

Это не так просто организовать.

Deleted
()
Ответ на: комментарий от ozz_is_here

AMD уже не альтернатива?

Амуда тоже дырява. Несколько по-иному, но тем не менее...

//Пользователь амуд.

Deleted
()

Наткнулся случайно в википедии:

https://en.wikipedia.org/wiki/Hyper-threading

In May 2005, Colin Percival demonstrated that a malicious thread on a Pentium 4 can use a timing attack to monitor the memory access patterns of another thread with which it shares a cache, allowing the theft of cryptographic information.

Еще в 2005-м году кто надо знал про возможность осуществления timing attack. И только сейчас потребовалось поднять хайп по этому поводу.

Версия, что Intel таким образом хочет поэффективнее впарить новые CPU не лишена смысла.

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

От это наговнякали хардварного говнокода.

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

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