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

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

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

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

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

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

с хера ли там меньшая производительность. они же P и С читать должны. а эти биты ничем не хуже лежащего рядом с ними U

http://wiki.osdev.org/images/9/9b/Page_table.png

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

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

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

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

Греющуюся?

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

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

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

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

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

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

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

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

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

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

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

когда

Амудуны всё ждут раскрытия потанцевала.

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

ГК РФ

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

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

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

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

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

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

нет, не увижу, отвечай до конца!

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

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

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

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

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

Нечего сказать? Отсекайся. И советую изучить понятие регистрации.

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

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

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

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

pf-9

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

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

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

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

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

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

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

ЛОЛ, был подписан на репу того скрипта-чекера, 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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