LINUX.ORG.RU

AMD чипы уязвимы к обоим вариантам Spectre

 , ,


2

3

В последний четверг (11 JAN 2018) AMD сообщила что ее чипы чувствительны к обоим варинатам Spectre. Днем позже AMD сообщила что риск от одного из них «близок к нулю». А патчи для Ryzen и EPYC исправляющие другой из них будут на этой неделе. Патчи для более старых процессоров обещаны на следующей неделе.

Эти новости привели к падению стоимости акций на 4%.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: tailgunner (всего исправлений: 4)

Ответ на: комментарий от kirk_johnson

Справку о том, что не верблюд, уже достал?

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

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

А PSP оттуда выпилишь?!

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

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

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

Читая один из тредов по данной уязвимости можно было заметить кк у некоторых были проблемы с тем чтобы найти её на интелах. Но скорее всего те кто проверяли были грамотными людьми и не просто копипастили PoC на удачу.

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

а нахера им досконально изучать - иди и посмотри в исходниках

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

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

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

Из этого нельзя утверждать ни присутствие ни отсутствие.

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

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

которую поломало была не из репозитория, но я пробовал и из него - все равно не работает, ругается на LSB...

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

схему то подходящую еще хер найдешь чтоб показать.

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

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

блок чтения памяти обращается в TLB, получает физ.адрес а ТАКЖЕ видит биты P, U, C, и т.д. в частности от бита P зависит вообще есть ли адрес. от бита C зависит можно ли спрашивать кэш или сразу читать внешнюю память. далее по полученному адресу он идет в кэш и там спрашивает строку. и вот тут возникает вопрос: а он что, ВСЕГДА туда ходит?

если например P=0 то страницы нет. откуда он будет читать? то есть в этой ситуации команда должна получать «отбой». в частности она может по прежнему двигаться по конвейеру мимо кэша но т.к. она помечена как всравшаяся, то в кэш можно не обращаться. там же нет обязанности каждый такт что-то читать.

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

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

Не постите про амуде, мам ну скажи им!

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

Своими активами не имеет права распоряжаться, как частный трейдер?

ГК РФ

Не только там школьники есть.

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

Апгрейд уровня лор.

Я может вообще бы не обновлялся, но плата стала всё чаще сбоить или обновился на что-нибудь покруче, однако UEFI, Intel ME, AMD PSP... не внушают доверия.

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

ПК на базе Intel работали быстрее AMD.

Откуда ты узнал что быстрее работал? )) Два компа рядом ставил и сравнивал? Если по бенчмаркам васяна с левого сайта, то интел во всех проплаченых бенчмарках для лохов всегда в топе.

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

Интелоговноеды придумали «потанцевал нераскрытай у AMD» — новинка отмазок.

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

Я может что-то не так понял, но по моему вы путаете Spectre и Meltdown.

Это Meltdown о чтении в кэш того, к чему у процесса нет доступа и это баг Intel.

Spectre если я правильно понимаю предполагает, что атакующий процесс особым образом «тренирует» branch prediction чтобы в атакуемом процессе (который имеет доступ куда надо) спекулятивно были бы выполнены команды, которые потом будут просто выброшены (но не содержат ошибок). Ну или как вариант атака на свой собственный процесс из «безопасной» среды где нет возможности прочитать произвольную память (например, из JavaScript исполняемого браузером прочитать произвольное место в памяти процесса браузера). С Meltdown у Spectre общий только способ узнать, что было прочитано в кэш.

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

да нет там OoO, ни на спарках ни на s390. ибо древние как гуано мамонта и тупые как пробка.

на SPARC есть и OoO, и Spectre. S390 - это слишком много машин, но как минимум на не совсем древних (последние 20 лет) есть OoO. И Spectre тоже есть.

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

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

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

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

а что тебе ещё говорить? что cray-1 сделали в 1975, ultrasparc в 95 и power3 в 98? так тебя тогда и в планах ещё не было, конечно ты и не знаешь. на вот, ознакомся с историей.

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

Сами амд призанли отсавание кукурузы в 52%, слейся уже. И да, у меня есть кукуруза и скайлейк, могу сравнить.

anonymous
()

pf-9

4.14 pf-9 Стало быстрее чем 8 с хотфиксом, спасибо.

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

Эм. При чем тут история. Это совершенно другая архитектура. Ты еще машину Тюринга вспомни..Лан, проехали

siropchik
()

Пришел вчера на работу, а у меня все машины АМДшные под офтопик с BSoD'ом. Удалил через консоль последнее обновление - всё вернулось на круги своя ;)

ЗЫ Слава индусам из Микрософт! )))

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

Да, фанбой интела нам конечно же покажет настоящие результаты теста,а не подтасованные. )) Ты себе докажи, мне не надо, я себе в 2003 уже всё доказал.

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

С тех пор 15 лет прошло, смартфоны появились, даже ниггер-президент был.

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

начиная с первых SPARC v9 подвержены, возможно вплоть до расширения инструкций ua2007. OSA2011(T5/M5) и OSA2015(S2/T7/M7/M8) уже нет. я прогонял немного модифицированный код из каноничного примера эксплойта spectre, как на х86, так и на sparc solaris и ничего он не может прочитать, даже на х86.

anonymous
()
Ответ на: комментарий от Novell-ch

ЛОЛ, был подписан на репу того скрипта-чекера, pull-requests, меняющие ответ скрипта про подврженность чипов AMD этим уязвимостям слали по несколько раз в день в зависимости от заяв того же AMD.

А на моей машине скрипт даёт вообще такой ответ:

\033[1;34mSpectre and Meltdown mitigation detection tool v0.31\033[0m

Checking for vulnerabilities against running kernel \033[35mDarwin 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64\033[0m
CPU is\033[35m\033[0m
We're missing some kernel info (see -v), accuracy might be reduced

\033[1;34mCVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'\033[0m
* Checking count of LFENCE opcodes in kernel: \033[103m\033[30m UNKNOWN \033[0m
> \033[46m\033[30mSTATUS:\033[0m \033[103m\033[30m UNKNOWN \033[0m (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal))

\033[1;34mCVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'\033[0m
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation
*     The SPEC_CTRL MSR is available: \033[103m\033[30m UNKNOWN \033[0m (couldn't read /dev/cpu/0/msr, is msr support enabled in your kernel?)
*     The SPEC_CTRL CPUID feature bit is set: \033[103m\033[30m UNKNOWN \033[0m (couldn't read /dev/cpu/0/cpuidr, is cpuid support enabled in your kernel?)
*   Kernel support for IBRS: \033[101m\033[30m NO \033[0m
*   IBRS enabled for Kernel space: \033[101m\033[30m NO \033[0m
*   IBRS enabled for User space: \033[101m\033[30m NO \033[0m
* Mitigation 2
*   Kernel compiled with retpoline option: \033[103m\033[30m UNKNOWN \033[0m (couldn't read your kernel configuration)
*   Kernel compiled with a retpoline-aware compiler: \033[103m\033[30m UNKNOWN \033[0m (couldn't find your kernel image or System.map)
> \033[46m\033[30mSTATUS:\033[0m \033[101m\033[30m VULNERABLE \033[0m (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

\033[1;34mCVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'\033[0m
* Kernel supports Page Table Isolation (PTI): \033[103m\033[30m UNKNOWN \033[0m (couldn't read your kernel configuration nor System.map file)
* PTI enabled and active: \033[101m\033[30m NO \033[0m
* Checking if we're running under Xen PV (64 bits): \033[104m\033[30m NO \033[0m
> \033[46m\033[30mSTATUS:\033[0m \033[101m\033[30m VULNERABLE \033[0m (PTI is needed to mitigate the vulnerability)

A false sense of security is worse than no security at all, see --disclaimer
Вопрос: знает ли ЯББЛ про такой ответ скрипта и нерхуа обновила свои ОСи для процев Intel и ARM-ов, которые она по лицензии сама же клепает :)

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

Тут немного особый случай. Производитель всегда старается оптимизировать свои издержки, так что будет использовать одинаковые решения насколько это возможно. То есть можно предположить с высокой степенью вероятности, что потроха у всех процессоров AMD примерно одинаковые, когда не доказано обратное (типа официальной смены микроархитектуры). И даже там части будут одинаковые. Ибо зачем разрабатывать дважды то, что уже работает? Есть варианты повышения производительности процессора кроме переделывания всего с нуля.

Так что какой-то выборки анализа процессоров достаточно, чтобы сделать выводы с высокой степенью вероятности (а что ты кроме вероятности хотел? у тебя даже не может быть уверенности, что завтра тебе не упадёт на голову кирпич - вероятность всегда есть - но это ведь не мешает тебе выходить на улицу без строительной каски и при этом не особо переживать по этому поводу?). Ибо вероятность того, что для одного конкретного экзотического процессора будут использовать другую систему страничной адресации, которая будет таки подвержена уязвимости, ничтожно мала. Зачем AMD так извращаться?

Именно поэтому наоборот все Intel за последние 10-20 лет подвержены уязвимости - опять же из-за переиспользования решений из поколения в поколение.

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

Ну а так что насчёт слайдов самой амд, шизя? И что ты там мог доказать когда в 2003 не было нынешних процессоров?

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

Слайдов AMD? Слайды, фризы на две секунды, подвисания на 3-4 секунды с заиканием звука, идеальная работа в меню игры, а в самой игре 2-3 фпс — это всё раковая опухоль интела в играх. У AMD по другому, по меню игры, в 99% случаев, можно легко судить о производительности игры в целом, как в меню работает такая же производительность будет и в игре.

И что ты там мог доказать когда в 2003 не было нынешних процессоров?

В 2003 мамонты ещё ходили, да. В 2003 я пересел на Duron 1350 уровня третьего пня из-за очередной сгоревшей материнки с пентиума 4 и не то что бы не обнаружил потери производительности на которую я рассчитывал, потому что тоже был фанбоем интела с промытыми маркетингом мозгами, а заметил что гораздо лучше производительность стала. Я в то время играл во Freelancer. По игре там со стороны планеты находилось около 200 кораблей номадов, вот на интеле тогда, когда камеру поворачиваешь в сторону скопления кораблей, происходило чудовищное падение производительности до неиграбельного состояния, отворачиваешься спиной к планете всё идеально. Когда уже перебрался на дюрон, в том же моменте когда глядишь в сторону планеты всё работало идеально как и в любую другую сторону если посмотреть. То есть, на системе почти топовой на тот момент (я за интел проц 9 тысяч рублей отвалил тогда, по нынешним это 90 тысяч рублей) производительность была ниже чем на системе на одно поколение ниже. Вот это был для меня тогда шок! Такой вот «сакральный» опыт был.

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

Ты читать разучился или просто тугой, что не можешь на простой вопрос ответить? Амд врет про отсос кукурузы на 52%?

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

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

Тогда это было связано с тем что Интел обкатывал на пользователях новую память DDR3, а АМД весьма удачно сделала ставку на DDR2. Мёд закончился когда DDR2 окончательно морально устарела.

Сейчас дела обстоят так что интел быстрее обсчитывает стейт-машины и стримы, а АМД - компилит кернел :-)

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

Просадку производительности можно наблюдать при определенных нагрузках, например при интенсивном I/O.

Записывал на флешку, копирую на hdd, стало сильнее тормозить.

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

Плюс скорее всего это было однопоточное приложение, 2003-й год все же, так что гипертрединг больше тормозил, чем приносил пользы. Ну и разрабы могли сделать ставку на FPU, а не SSE, и гонять данные небольшими порциями, что уменьшало выгоду от пропускной способности пня, но давала по таймингам выгоду AMD.

У меня было две игровые машинки как раз атлон xp и p4. Даже видел рекомендации гасить гипертрединг в ряде игр.

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

Ну сейчас тоже не особо пользы от гипертрединга. Лучшая альтернатива гипертредингу - XEN.

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