Охренеть! Слышал про это краем уха, но не думал что дело обстоит таки образом. То есть получается что все современные процессоры — это тупиковая ветвь и нужно разрабатывать новые архитектуры, учитывающие подобные уязвимости. Да, интересно будет понаблюдать за развитием событий. Дмитрий, спасибо за рассказ!
Не тупиковая ветвь, полагаю, достаточно пофиксить доступ к кешу. Переход на другую архитектуру, в любом случае, будет куда более болезненным и в принципе не может произойти единовременно
Спасибо! Всё очень доходчиво разъяснено.
«Понравилось» как поступил CEO Intel. Красавчик вообще. В США за такое не сажают разве? Я имею в виду за слив акций на основе инсайдерской инфы.
Там не всё так однозначно.
В случаи руководителя технологичной компании продажа акций собственной компании проводится по особому порядку (в источники значится как Rule 10b5-1(c) trading plans) с заранее оговоренным временем продажи, так что это не то чём можно от раза к разу «срывать» банк.
А какую уязвимость использует Спектр? В видео говорится, что Спектр использует уязвимость разных процессоров. В том числе и конкурирующих, и вряд ли они делились наработками друг с другом. Случаем не дыра ли эта для спецслужб?
Вот и подкастики появились :).
Теперь осталось их в mp3 (а лучше в m4a) куда-нибудь на подкаст терминал выкладывать что-бы был нормальный RSS фид для всяческих Podcast приложений.
Привет! тот самый случай что терять нечего а все таки неприятный осадок((( интересно говорят про 2010 год подразумевая серию «core i»? сижу на квадах, вряд ли микрокод к этим материкам обновят, остается надежда на энтузиастов которые после выхода патча на актуальное железо сделают патчеры биосов новых матерей… Ситуация похожа на времена вируса в народе прозванным «Чернобыль», и тогда и сейчас это било на материальную часть, вот только тогда это было железо а сейчас данные((((
Уже не про 2010-й, а вроде как всё начиная с Pentium (в смысле самый первый который).
И микрокодом это к сожалению не лечится, в это вся боль и заключается.
Дмитрий, объясните пожалуйста, а от обновления микрокода есть -30% к производительности? Просто если атака должна быть очень целевой, лучше и не обновляться простому юзеру?
Опасностью этого можно считать тотальное заражение всего что только есть, а не просто дамп.
Я об этом думал 3 года назад, но сказали мол чушь несешь, теперь так не считаю.
В который раз убеждаюсь, насколько просто и доступно ты объясняешь сложные вещи, спасибо)
Не думаеш запустить обучающие (или обьясняющие) видео типа «сетевых технологий» (пусть даже у формате «видео на салфетке»?
Спасибо за инфу.
Вроде как для семёрки обновление безопасности тоже вышло, по крайней мере в списке ОС получивших обновление она теперь тоже есть.
Правда мне с моим Core2Duo обновление микрокода вряд ли светит.
Спасибо за разъяснение! Нигде не могу найти информацию об нашем дорогом и любимом Эльбрусе и вообще об архитектуре VLIW, она подвержена уязвимости или просто не изучена ввиду крайней распространённости?
Интересно, что на Фряху вообще нет патча
«About the Meltdown and Spectre attacks: FreeBSD was made aware of the problems in late December 2017. We’re working with CPU vendors and the published papers on these attacks to mitigate them on FreeBSD. Due to the fundamental nature of the attacks, no estimate is yet available for the publication date of patches.»
Дмитрий, доброго времени суток. Не могли бы вы обьяснить подробнее про эти уязвимости. То что инструкции выполняются напрямую «на ассемблере процессора» в обход ОС, это понятно. Но не понятно каким образом злоумышленнику возвращается результат. Ведь для (допустим удалённой) отправки к «хозяину» результатов хулиганского кода требуется доступ в сеть, а это уже задействуются механизмы ОС (драйвера сетевух и подобное). Я понимаю что если код загружен до того как грузанётся ядро, то для оси оно всё прозрачно, но опять же, для этого нужна перезагрузка ОС и «подхват инфекции». Сбила с толку ваша фраза: «…от этого, пользователя защитит ядро ОС, которое не даст делать всё что захочеться… (но сам процессор главнее и запущенный) …банальный скрипт на недобросовестном сайте способен получить ваши данные, включая из защищенной памяти». Я понимаю разницу между эксплойтом и вирусом, но каким мокаром сам проц «лезет в стетвую карту» что бы отправить считаный дамп. В случае же если отправка осуществляется в обход ОС, то как мне кажется это невероятно сложно реализовать, ведь у всех разное железо. Извиняюсь за растянутый вопрос, сам не шибко хорошо разбираюсь в этой теме, потому описал как мог.
Давайте еще раз, совсем на пальцах. Ничего в обход ОС не исполняется. Программа, какая бы то ни было — это в любом случае код, интерпретируемо или напрямую, но исполняемый процессором, и ОС — такая же программа, как и любая другая, под ней работающая. Просто ОС — это первая программа, загружающаяся при старте компьютера, именно она, выражаясь по-старому, получает управление от BIOSа и переводит процессор в защищенный режим (все x86 процессоры как и тридцать лет назад стартуют в реальном режиме). Это даёт ОСи быть для процессора авторитетнее других программ. Интерпретируемо (то есть по средствам компилятора на лету, если код написан на языках вроде ДжаваСкрипта или, там, Перла, Питона, Руби и так далее) или нет (если программа написана на Си или даже прям на ассемблере), но любая программа может (и должна) делать всё то же самое, что и операционная система — читать любую область памяти компьютера, просить процессор выполнять любые операции, получать доступ к любому оборудованию. Но если ОСь загружена, и процессор переведен в защищенный режим, то ОСь может отказать программе в доступе, и программа не сможет считать какую-то область памяти, принадлежащую, например, другой программе или ядру самой ОСи. Это позволяет нам иметь многозадачность и стабильность (то есть гарантию, что программа, даже если помрёт сама, не потащит за собой в ад остальные программы, а просто, выполнив недопустимую операцию, будет закрыта только она одна). Допустим, есть нормальный сайт, где есть код на ДжаваСкрипте, который специально для вашего удобства делает какие-то операции на вашем компьютере. Браузер и система дадут ему выполнится, они для того и нужны, чтобы всё работало. Система сама предоставит свой tcp-стек для передачи данных от сайта к вашему компьютеру и обратно, а браузер интерпретирует скрипт в ассемблер и выполнит на вашем процессоре. Так оно у вас и работает изо дня в день, так и должно быть. Если же скрипт недобросовестный и захочет прочитать область памяти вашего компьютера, где, скажем, ваш браузер хранит пароли автозаполнения — он наткнется на кучу препятствий в лице как самого браузера, так и охраняющую вашу память операционную систему. Мы увидим ошибку вроде Access Violation по адресу такому-то, и на этом всё, скрипт будет убит. Но что это вообще значит? Это значит, что операционная система будет выполнять на процессоре некую задачу по обеспечению работоспособности скрипта, и в какой-то момент, когда скрипт захочет «слишком многого», операционная система просто остановит его выполнение. Так вот суть уязвимости в том, что к моменту, когда произойдет попытка превысить полномочия, процессор, благодаря своей фиче спекулятивного, то есть опережающего вычисления, уже по сути выполнит задачу скрипта, получит результат работы, и будет ждать, когда операционная система захочет этот результат работы скрипта выдать тому сайту, используя, естественно, свои собственные возможности доступа в сеть и всё остальное. Но операционная система данные эти не запросит, то есть не переведет их в область своей защищенной памяти. Однако из-за ошибки в дизайне процессора по сути эти данные, которые не должны были появиться на свет — всё таки появились и лежат в области памяти, которую ни процессор и система не считают защищенной областью. Система считает, что остановила скрипт раньше, чем он попросил процессор выдать ему информацию из ядерной оперативной памяти, а на самом деле процессор уже успел это сделать, потому что предсказал, что следующим шагом скрипт именно этого и захочет. И вот продемонстрированный исследователями этой уязвимости эксперимент показал, что процессор можно вот так вот спровоцировать выдать кому угодно шаг за шагом содержимое всей вашей оперативной памяти, а передавать эти данные будет сама Ось, её браузер и все остальные инструменты, которые просто не будут знать, что эти данные на самом деле — копия тех данных, что лежат под семью замками, для них это будут просто никому не нужные данные из никем не охраняемой области. Это еще более упрощенно, чем в видео.
Ну, если еще проще, то выглядит это примерно так:
Скрипт: «Привет, система, сделай копию данных ячейки памяти А в ячейку памяти Б»
Процессор: «Я пока сделаю копию, а вы там разбирайтесь сами, чего кому можно, а что нельзя. Вдруг можно, а у меня уже раз — и всё готово»
Система: «Хрен тебе, ячейка памяти А — это память моего ядра, и скриптам читать её не разрешается»
Скрипт: «Система, тогда выдай мне пожалуйста данные из ячейки памяти Б»
Система: «без проблем, эта память ничья и ничего полезного там нет, забирай».
Большое спасибо за развернутый ответ, виноват мой взгляд на ситуацию. Я ошибочно считал что вызов инструкций идёт на «низком уровне» отсюдова и путаница.
В конечном счете вызов инструкций идёт на низком уровне, но передача данных вполне может быть запрошена у любого стороннего инструментария, например у tcp-стека операционной системы, а на самом деле даже выше — на уровне браузера.
>>все x86 процессоры как и тридцать лет назад стартуют в реальном режиме
непринципиальная поправка, но все же в современных системах в защищенный режим переводит UEFI при инициализации (если режим совместиости с legacy BIOS отключен)
Основная проблема в TLB и счетчике перфоманса rdtsc — теоретически патч cr4 регистра (бит TSC кажется) запретит rdtsc и померять время доступа к ячейке памяти не получится, но вся проблема в том что сегодня приложения нуждаются в точном таймере. Т.е. на сейчас закрыть уязвимость в любом случае не получится. Intel (и остальные) нарушили основной паттерн проектирования секьюрности — говоря простым языком — нам позволяют заглянуть(пройти не позволяют) за замкнутые ворота прежде чем проверить подойдет ли наш ключ к этим воротам.
Паранойя mode on.
Уязвимости больше двадцати лет и типа недавно заметили.
Я и раньше считал криптографию фиговым листком. Из-за Intel Management Engine и подобных бэкдоров. Теперь причин так считать ещё больше.
Товарищи, нужна помощь( нагуглить невышло). Возможно ли в prboom подрубить оргинальную музыку из doom и doom 2? А то там какой-то шлак. Все как то странно рычат и тд.
вы ему doom.wad или doom2.wad от оригинальной игры дайте (то есть положите в директорию с prboom-мом), и всё будет, и уровни, и звуки и музыка оригинальные
Я понял в чем была проблема, но все равно спасибо за то что не поленились написать и попытаться помочь. Если вдруг интересно, то проблема была в midi музыке. Не хотел комп ее воспроизводить. Поставил timidity и все стало хорошо.
the branch predictor would sometimes cause xdcbt [xdcbt is toxic it leads to incoherent memory] instructions to be speculatively executed and that was just as bad as really executing them
И всё же интересно как эти уязвимости коснулись наших эльбрусов. Не в смысле практической реализации утечки данных на существующих системах. А именно как самого факта возможности организовать эти утечки.
Другими словами есть ли в Эльбрусах некое подобие предсказателей по выполнению кода?
Архитектура эльбрусов — очень длинный набор команд, т.е. все что будет делать процессор решает компилятор. Иначе говоря если такого рода ошибки там есть, то что бы от них избавиться достаточно пропатчить компилятор и пересобрать бинарники.
Выходит так, что у Эльбрусов есть преимущество над Intel и AMD. Жаль, что отечественные процессоры на данный момент простым смертным недоступны и, скорее всего, будут оставаться недоступными довольно продолжительное время.
В конечном итоге, сколько бы не было уязвимостей в процессорах Intel, он останется на передовых позициях продаж! Дырки всегда и везде будут, не зря же Пентагон взламывают, значится система не совершена.Все равно остаюсь только за процессоры Intel.
При современном подходе к разработке, типа мы продали её вчера, инженер — становись в позу зю и фигач. А также не совершенстве инструментария, принципиально не допускающего отсутствие ошибок, 50 человек тестеров за программистом не успевают. Ситуация в области IT будет остоватся неудовлетворительной. И беспокоит это только тех, кого бъёт по карману.
Вооот. Вот поэтому я растянул новогодний выпуск аж до конца января. Дим, там староновогоднего выпуска, случаем, не предвидится? А то до весны ещё далеко… Хнык-хнык.
А вот я — молодец — не докучаю Дмитрию фразами — «ну когда же уже новые ролики? :(…»
Сказал «до весны», значит — до весны… Стиснул зубы и терпеливо жду, перебиваясь другим схожим и не очень контентом… а скоро весна… Дима уже скоро? Дима, давно ждём! Мы изголодалися! Димааааа!!!…
… а… ну то есть — ждём молча, ничуть не беспокоим, не тревожим человека в творческом отпуске. Ждём! Ждём? Ждём.
🙂
Дмитрий ещё вопрос, про графические технологии. Очень трудно разобраться в громаде текста которые удается найти по поводу:
HLSL (High-Level Shader Language)
DirectX, а именно каковы особенности каждой номерной версии, в частности начиная с 8.0 до 12.0 Информации технической много, но сам черт ногу сломит, понять что именно добавлялось и изменялось от версии к версии. Разумеется, только основное бы. Понятно, что как раз так менялась версия HLSL.
Далее, интересуют такие навороты графики как:
SSAO (Screen-Space Ambient Occlusion)
HBAO (Horizon-Based Ambient Occlusion) и HDAO (High-Definition Ambient Occlusion).
В чём их принципиальное различие непонятно. Известно лишь ,что первый (HBAO) это технология Nvidia, а второй (HDAO) это AMD.
Интересуют также, CHSs (Contact-Hardening Soft Shadows) что есть такое.
Ну и наконец, CUDA (Compute-Unified Device Architecture).
Хотелось бы больше проверенной инфы, с источниками что ли. В википедии многое непонятно откуда.
Не дай вражине завладеть личными данными — разломай свой компьютер! 🙂
Охренеть! Слышал про это краем уха, но не думал что дело обстоит таки образом. То есть получается что все современные процессоры — это тупиковая ветвь и нужно разрабатывать новые архитектуры, учитывающие подобные уязвимости. Да, интересно будет понаблюдать за развитием событий. Дмитрий, спасибо за рассказ!
Не тупиковая ветвь, полагаю, достаточно пофиксить доступ к кешу. Переход на другую архитектуру, в любом случае, будет куда более болезненным и в принципе не может произойти единовременно
Только вот собрал 1й комп на Intel и на тебе, облом такой. Надеюсь меня никто взламывать не собирается.
Спасибо! Всё очень доходчиво разъяснено.
«Понравилось» как поступил CEO Intel. Красавчик вообще. В США за такое не сажают разве? Я имею в виду за слив акций на основе инсайдерской инфы.
PS Вот еще «на почитать»: https://meltdownattack.com/
Могут и посадить, да.
P.S. эта ссылка есть в описании ролика на ютубе.
Там не всё так однозначно.
В случаи руководителя технологичной компании продажа акций собственной компании проводится по особому порядку (в источники значится как Rule 10b5-1(c) trading plans) с заранее оговоренным временем продажи, так что это не то чём можно от раза к разу «срывать» банк.
http://www.businessinsider.com/intel-ceo-krzanich-sold-shares-after-company-was-informed-of-chip-flaw-2018-1
А какую уязвимость использует Спектр? В видео говорится, что Спектр использует уязвимость разных процессоров. В том числе и конкурирующих, и вряд ли они делились наработками друг с другом. Случаем не дыра ли эта для спецслужб?
Дмитрий, вы не планировали сделать в Телеграмме канал и выкладывать туда короткие новости, комментарии, подкасты и прочее?
Рано или поздно нечто подобное должно было случиться, учитывая то, сколько закладок было заложено в intel-совместимые процессоры. То ли ещё будет…
В комментариях на Ютубе просто детский сад…
Вот и подкастики появились :).
Теперь осталось их в mp3 (а лучше в m4a) куда-нибудь на подкаст терминал выкладывать что-бы был нормальный RSS фид для всяческих Podcast приложений.
Привет! тот самый случай что терять нечего а все таки неприятный осадок((( интересно говорят про 2010 год подразумевая серию «core i»? сижу на квадах, вряд ли микрокод к этим материкам обновят, остается надежда на энтузиастов которые после выхода патча на актуальное железо сделают патчеры биосов новых матерей… Ситуация похожа на времена вируса в народе прозванным «Чернобыль», и тогда и сейчас это било на материальную часть, вот только тогда это было железо а сейчас данные((((
Уже не про 2010-й, а вроде как всё начиная с Pentium (в смысле самый первый который).
И микрокодом это к сожалению не лечится, в это вся боль и заключается.
Но это первое, что сделал Интел. Обновил микрокод. https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File
Дмитрий, объясните пожалуйста, а от обновления микрокода есть -30% к производительности? Просто если атака должна быть очень целевой, лучше и не обновляться простому юзеру?
[тусуемся]
— О-па, процессоры ломанули…
— А-а, пофиг!
[тусуемся дальше]
Опасностью этого можно считать тотальное заражение всего что только есть, а не просто дамп.
Я об этом думал 3 года назад, но сказали мол чушь несешь, теперь так не считаю.
В который раз убеждаюсь, насколько просто и доступно ты объясняешь сложные вещи, спасибо)
Не думаеш запустить обучающие (или обьясняющие) видео типа «сетевых технологий» (пусть даже у формате «видео на салфетке»?
Спасибо Дим!!!
Спасибо за инфу.
Вроде как для семёрки обновление безопасности тоже вышло, по крайней мере в списке ОС получивших обновление она теперь тоже есть.
Правда мне с моим Core2Duo обновление микрокода вряд ли светит.
Вот здесь http://blog.cyberus-technology.de/posts/2018-01-03-meltdown.htm lесть код на ассамблере с объяснением как Meltdown происходит. Коротко и по делу. Правда, текст предполагает некоторые базовые знания.
Спасибо за разъяснение! Нигде не могу найти информацию об нашем дорогом и любимом Эльбрусе и вообще об архитектуре VLIW, она подвержена уязвимости или просто не изучена ввиду крайней распространённости?
Интересно, что на Фряху вообще нет патча
«About the Meltdown and Spectre attacks: FreeBSD was made aware of the problems in late December 2017. We’re working with CPU vendors and the published papers on these attacks to mitigate them on FreeBSD. Due to the fundamental nature of the attacks, no estimate is yet available for the publication date of patches.»
Дмитрий, доброго времени суток. Не могли бы вы обьяснить подробнее про эти уязвимости. То что инструкции выполняются напрямую «на ассемблере процессора» в обход ОС, это понятно. Но не понятно каким образом злоумышленнику возвращается результат. Ведь для (допустим удалённой) отправки к «хозяину» результатов хулиганского кода требуется доступ в сеть, а это уже задействуются механизмы ОС (драйвера сетевух и подобное). Я понимаю что если код загружен до того как грузанётся ядро, то для оси оно всё прозрачно, но опять же, для этого нужна перезагрузка ОС и «подхват инфекции». Сбила с толку ваша фраза: «…от этого, пользователя защитит ядро ОС, которое не даст делать всё что захочеться… (но сам процессор главнее и запущенный) …банальный скрипт на недобросовестном сайте способен получить ваши данные, включая из защищенной памяти». Я понимаю разницу между эксплойтом и вирусом, но каким мокаром сам проц «лезет в стетвую карту» что бы отправить считаный дамп. В случае же если отправка осуществляется в обход ОС, то как мне кажется это невероятно сложно реализовать, ведь у всех разное железо. Извиняюсь за растянутый вопрос, сам не шибко хорошо разбираюсь в этой теме, потому описал как мог.
Давайте еще раз, совсем на пальцах. Ничего в обход ОС не исполняется. Программа, какая бы то ни было — это в любом случае код, интерпретируемо или напрямую, но исполняемый процессором, и ОС — такая же программа, как и любая другая, под ней работающая. Просто ОС — это первая программа, загружающаяся при старте компьютера, именно она, выражаясь по-старому, получает управление от BIOSа и переводит процессор в защищенный режим (все x86 процессоры как и тридцать лет назад стартуют в реальном режиме). Это даёт ОСи быть для процессора авторитетнее других программ. Интерпретируемо (то есть по средствам компилятора на лету, если код написан на языках вроде ДжаваСкрипта или, там, Перла, Питона, Руби и так далее) или нет (если программа написана на Си или даже прям на ассемблере), но любая программа может (и должна) делать всё то же самое, что и операционная система — читать любую область памяти компьютера, просить процессор выполнять любые операции, получать доступ к любому оборудованию. Но если ОСь загружена, и процессор переведен в защищенный режим, то ОСь может отказать программе в доступе, и программа не сможет считать какую-то область памяти, принадлежащую, например, другой программе или ядру самой ОСи. Это позволяет нам иметь многозадачность и стабильность (то есть гарантию, что программа, даже если помрёт сама, не потащит за собой в ад остальные программы, а просто, выполнив недопустимую операцию, будет закрыта только она одна). Допустим, есть нормальный сайт, где есть код на ДжаваСкрипте, который специально для вашего удобства делает какие-то операции на вашем компьютере. Браузер и система дадут ему выполнится, они для того и нужны, чтобы всё работало. Система сама предоставит свой tcp-стек для передачи данных от сайта к вашему компьютеру и обратно, а браузер интерпретирует скрипт в ассемблер и выполнит на вашем процессоре. Так оно у вас и работает изо дня в день, так и должно быть. Если же скрипт недобросовестный и захочет прочитать область памяти вашего компьютера, где, скажем, ваш браузер хранит пароли автозаполнения — он наткнется на кучу препятствий в лице как самого браузера, так и охраняющую вашу память операционную систему. Мы увидим ошибку вроде Access Violation по адресу такому-то, и на этом всё, скрипт будет убит. Но что это вообще значит? Это значит, что операционная система будет выполнять на процессоре некую задачу по обеспечению работоспособности скрипта, и в какой-то момент, когда скрипт захочет «слишком многого», операционная система просто остановит его выполнение. Так вот суть уязвимости в том, что к моменту, когда произойдет попытка превысить полномочия, процессор, благодаря своей фиче спекулятивного, то есть опережающего вычисления, уже по сути выполнит задачу скрипта, получит результат работы, и будет ждать, когда операционная система захочет этот результат работы скрипта выдать тому сайту, используя, естественно, свои собственные возможности доступа в сеть и всё остальное. Но операционная система данные эти не запросит, то есть не переведет их в область своей защищенной памяти. Однако из-за ошибки в дизайне процессора по сути эти данные, которые не должны были появиться на свет — всё таки появились и лежат в области памяти, которую ни процессор и система не считают защищенной областью. Система считает, что остановила скрипт раньше, чем он попросил процессор выдать ему информацию из ядерной оперативной памяти, а на самом деле процессор уже успел это сделать, потому что предсказал, что следующим шагом скрипт именно этого и захочет. И вот продемонстрированный исследователями этой уязвимости эксперимент показал, что процессор можно вот так вот спровоцировать выдать кому угодно шаг за шагом содержимое всей вашей оперативной памяти, а передавать эти данные будет сама Ось, её браузер и все остальные инструменты, которые просто не будут знать, что эти данные на самом деле — копия тех данных, что лежат под семью замками, для них это будут просто никому не нужные данные из никем не охраняемой области. Это еще более упрощенно, чем в видео.
Ну, если еще проще, то выглядит это примерно так:
Скрипт: «Привет, система, сделай копию данных ячейки памяти А в ячейку памяти Б»
Процессор: «Я пока сделаю копию, а вы там разбирайтесь сами, чего кому можно, а что нельзя. Вдруг можно, а у меня уже раз — и всё готово»
Система: «Хрен тебе, ячейка памяти А — это память моего ядра, и скриптам читать её не разрешается»
Скрипт: «Система, тогда выдай мне пожалуйста данные из ячейки памяти Б»
Система: «без проблем, эта память ничья и ничего полезного там нет, забирай».
Большое спасибо за развернутый ответ, виноват мой взгляд на ситуацию. Я ошибочно считал что вызов инструкций идёт на «низком уровне» отсюдова и путаница.
В конечном счете вызов инструкций идёт на низком уровне, но передача данных вполне может быть запрошена у любого стороннего инструментария, например у tcp-стека операционной системы, а на самом деле даже выше — на уровне браузера.
>>все x86 процессоры как и тридцать лет назад стартуют в реальном режиме
непринципиальная поправка, но все же в современных системах в защищенный режим переводит UEFI при инициализации (если режим совместиости с legacy BIOS отключен)
Прям как партия в шахматы, просчитать на несколько ходов вперёд =)
Основная проблема в TLB и счетчике перфоманса rdtsc — теоретически патч cr4 регистра (бит TSC кажется) запретит rdtsc и померять время доступа к ячейке памяти не получится, но вся проблема в том что сегодня приложения нуждаются в точном таймере. Т.е. на сейчас закрыть уязвимость в любом случае не получится. Intel (и остальные) нарушили основной паттерн проектирования секьюрности — говоря простым языком — нам позволяют заглянуть(пройти не позволяют) за замкнутые ворота прежде чем проверить подойдет ли наш ключ к этим воротам.
> нам позволяют заглянуть(пройти не позволяют) за замкнутые ворота прежде чем проверить подойдет ли наш ключ к этим воротам.
очень точная метафора
Так может вообще отключить спекулятивное выполнение на время, пока ворота не сделают непрозрачными?
Паранойя mode on.
Уязвимости больше двадцати лет и типа недавно заметили.
Я и раньше считал криптографию фиговым листком. Из-за Intel Management Engine и подобных бэкдоров. Теперь причин так считать ещё больше.
Обновил все свои Windows и Linux. Надеюсь что роутер не ломанут 🙂
Товарищи, нужна помощь( нагуглить невышло). Возможно ли в prboom подрубить оргинальную музыку из doom и doom 2? А то там какой-то шлак. Все как то странно рычат и тд.
вы ему doom.wad или doom2.wad от оригинальной игры дайте (то есть положите в директорию с prboom-мом), и всё будет, и уровни, и звуки и музыка оригинальные
Я понял в чем была проблема, но все равно спасибо за то что не поленились написать и попытаться помочь. Если вдруг интересно, то проблема была в midi музыке. Не хотел комп ее воспроизводить. Поставил timidity и все стало хорошо.
Вот тут https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/ есть описание, что нечто подобное было обнаружено на XBox 360 ещё в 2005 г., правда, широко тогда она не стало известно, на сколько я понял.
the branch predictor would sometimes cause xdcbt [xdcbt is toxic it leads to incoherent memory] instructions to be speculatively executed and that was just as bad as really executing them
И всё же интересно как эти уязвимости коснулись наших эльбрусов. Не в смысле практической реализации утечки данных на существующих системах. А именно как самого факта возможности организовать эти утечки.
Другими словами есть ли в Эльбрусах некое подобие предсказателей по выполнению кода?
Архитектура эльбрусов — очень длинный набор команд, т.е. все что будет делать процессор решает компилятор. Иначе говоря если такого рода ошибки там есть, то что бы от них избавиться достаточно пропатчить компилятор и пересобрать бинарники.
Выходит так, что у Эльбрусов есть преимущество над Intel и AMD. Жаль, что отечественные процессоры на данный момент простым смертным недоступны и, скорее всего, будут оставаться недоступными довольно продолжительное время.
В конечном итоге, сколько бы не было уязвимостей в процессорах Intel, он останется на передовых позициях продаж! Дырки всегда и везде будут, не зря же Пентагон взламывают, значится система не совершена.Все равно остаюсь только за процессоры Intel.
При современном подходе к разработке, типа мы продали её вчера, инженер — становись в позу зю и фигач. А также не совершенстве инструментария, принципиально не допускающего отсутствие ошибок, 50 человек тестеров за программистом не успевают. Ситуация в области IT будет остоватся неудовлетворительной. И беспокоит это только тех, кого бъёт по карману.
Дима, куда пропал, скучаем?!
Всё было ясно сказано в новогоднем выпуске, да и не первый год такая схема.
Это всё понятно, но всё-равно скучно.
Вооот. Вот поэтому я растянул новогодний выпуск аж до конца января. Дим, там староновогоднего выпуска, случаем, не предвидится? А то до весны ещё далеко… Хнык-хнык.
Qraizer, хнык-хнык не надо, это не поможет. Главное что мы напомнили Диме о себе.
А вот я — молодец — не докучаю Дмитрию фразами — «ну когда же уже новые ролики? :(…»
Сказал «до весны», значит — до весны… Стиснул зубы и терпеливо жду, перебиваясь другим схожим и не очень контентом… а скоро весна… Дима уже скоро? Дима, давно ждём! Мы изголодалися! Димааааа!!!…
… а… ну то есть — ждём молча, ничуть не беспокоим, не тревожим человека в творческом отпуске. Ждём! Ждём? Ждём.
🙂
Ну он же сказал, что безопасно будет на пару месяцев из инета свалить. 🙂
Дима помню обмолвился, что хотел бы комьюнити собрать на базе своего музея или нет?
КАГДА УЖЕ НОВЫЕ ВИДЕО? ВСЁ, ДИЗЛАЙК АТПИСКА!
А У ВАС И ПАТПИСКИ НЕ БЫЛО НИКОГДА, РАЗ НЕ ЗНАЕТЕ, КОГДА НОВОЕ ВИДЕО
Айболат явно не в себе, не выдержал….. R.I.P.
Дима, хоть «на салфетке» чего выпусти, а то реально грустно.
Дмитрий, что думаешь про такие игры как Escape from Tarkov и Kingdom Come: Deliverance ?
Дмитрий ещё вопрос, про графические технологии. Очень трудно разобраться в громаде текста которые удается найти по поводу:
HLSL (High-Level Shader Language)
DirectX, а именно каковы особенности каждой номерной версии, в частности начиная с 8.0 до 12.0 Информации технической много, но сам черт ногу сломит, понять что именно добавлялось и изменялось от версии к версии. Разумеется, только основное бы. Понятно, что как раз так менялась версия HLSL.
Далее, интересуют такие навороты графики как:
SSAO (Screen-Space Ambient Occlusion)
HBAO (Horizon-Based Ambient Occlusion) и HDAO (High-Definition Ambient Occlusion).
В чём их принципиальное различие непонятно. Известно лишь ,что первый (HBAO) это технология Nvidia, а второй (HDAO) это AMD.
Интересуют также, CHSs (Contact-Hardening Soft Shadows) что есть такое.
Ну и наконец, CUDA (Compute-Unified Device Architecture).
Хотелось бы больше проверенной инфы, с источниками что ли. В википедии многое непонятно откуда.
Не все осилили новогодний выпуск. Я уже думал что ты отъехал, месяц без видео.
Дмитрий, если возможно, не могли бы Вы в цикле передач «Кремневые титаны» рассказать про компанию Cray Inc и их суперкомпьютеры.
БЛин долго то как…