https://opennet.ru/openforum/vsluhforumID3/119996.html Группа исследователей из Грацского технического университета (Австрия), ранее известная разработкой методов атак MDS, NetSpectre, Throwhammer и ZombieLoad, провела исследование специфичных для процессоров AMD аппаратных оптимизаций и разработала два новых метода атак по сторонним каналам, манипулирующих утечками данных в процессе работа механизма предсказания каналов кэша первого уровня процессоров AMD. Методы могут использоваться как для снижения эффективности защиты ASLR, так и для определения содержимого областей памяти ядра и других процессов, обрабатываемых на том же ядре CPU...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52501<br> https://opennet.ru/openforum/vsluhforumID3/119996.html#206 Mon, 16 Mar 2020 09:53:05 GMT &gt; опетероны же к10 архи, она не подверженна данной атаке <br><br>Бульдозеры и Кучевозы вроде подвержены. 3200/4200/6200+<br>https://en.wikipedia.org/wiki/List_of_AMD_Opteron_microprocessors<br> https://opennet.ru/openforum/vsluhforumID3/119996.html#205 Mon, 16 Mar 2020 06:37:23 GMT опетероны же к10 архи, она не подверженна данной атаке<br> https://opennet.ru/openforum/vsluhforumID3/119996.html#203 Sun, 15 Mar 2020 20:05:22 GMT Некорерктно выразился, имел ввиду погнуть.<br> https://opennet.ru/openforum/vsluhforumID3/119996.html#202 Sun, 15 Mar 2020 19:59:12 GMT &gt;Всё дело в том что любое упреждающего чтения памяти неэффективно <br>&gt; Как раз на нем все и держится. <br><br>Наглый бред.<br><br>&gt; Если на каждую операцию взять ячейки один по смещению 1 от указателя и сложить с ячейкой два по смещению 2 от указателя приходилось бы 4 раза ждать память - эффекта от быстрого проца не было бы никакого. <br><br>Именно для этого изобрели кэш(и)...<br><br>&gt; Посему во времена оные и перешли на память с большим объемом кешлайна для обмена с процом (сначала по 32, а потом и по 64 байта за прием). <br><br>"память с большим объемом кешлайна" - nocomment.<br><br>&gt; Ибо адресовать приходится большой объем памяти (дело пошло на терабайты), а поиск адреса чем он длиннее - тем он дольше. <br><br>Там нет никого поиска, всё аппаратно параллельно и быстро. <br> https://opennet.ru/openforum/vsluhforumID3/119996.html#201 Sun, 15 Mar 2020 19:44:58 GMT &gt; Неисправность в незадокументированной области? Т.е. в документации было четко описано, что кеш выделяется только для одного процесса <br><br>Закономерно, вообще то.<br><br>&gt; и другой процесс воспользоваться наличием данных в нем не может? Или все-таки не описано? <br><br>В соответствии с докуменатцией - даже может, но только если он системный. В Ring0 - можно, через команды управления кэшем.<br><br>&gt; Дело в том, что быстрый кеш с полным разбором адреса сделать в рамках транзисторного бюджета не могут. <br><br>Бред.<br><br>&gt; А уж делать все проверки помимо этого и дробить кеш по PID вообще заоблачно. <br><br>Если уже не перепутал, ~так всё и делается или может по физадресу, без этого бы ничего не работало бы.<br><br>&gt; Тут еще выяснилось, что с уменьшением техпроцесса даже поддержать транзисторный бюджет на старом уровне штеуду не удается, что уж говорить о его наращивании. <br><br>Ещё не встречал столко заблуждений в одном сообщении... Трудно аргументирванно отвечать на абсурд.<br><br>&gt; Зря что-ль АМД стала дробить проц на чиплеты? <br><br>Так им тупо дешев https://opennet.ru/openforum/vsluhforumID3/119996.html#200 Sat, 14 Mar 2020 06:45:07 GMT Речь идёт о сафари времён, когда он вовсю выпускался под винду, притом, относительно старая из версий.<br>И, да, это было реально быстрой штукой( на 128мб и селеррне, вроде, на 900мгц ), да и сами страницы быстро открывались Джан на медленном тырнете.<br>Но, да, в те времена 100+ вкладок я не открывал.<br><br>Хром, вроде, появился уже позже и быстрым, даже самые первые версии, нифига не были - это было глючное и тормозное ***, по ощущениям - IE с немного измененным дизайном.<br> https://opennet.ru/openforum/vsluhforumID3/119996.html#199 Wed, 11 Mar 2020 13:52:03 GMT Поломать ноги ещё нужно очень постараться - они достаточно прочные для своих размеров. Я вот по молодости в общаге на Athlon 64 припаивал 2 оторванные ноги просто потому, что процессор достался почти нахаляву за 2л пива, а стоил как моя полугодовая стипендия. Ещё пару лет назад этот проц спокойно себе работал, пока не был окончательно списан в гараж )<br> https://opennet.ru/openforum/vsluhforumID3/119996.html#198 Wed, 11 Mar 2020 13:41:28 GMT &gt; Дыры процессора - не проблема ОС, а владельца пользющегося полуается всяким халтурным <br>&gt; дерьмом <br>&gt; и по нормальному: производителя процессора - ОБЯЗАННОГО заменять некондицию или вернуть <br>&gt; деньги, <br><br>Демагогия! В любом сложном продукте есть баги обязательно.<br>Микрокодами баги в процессоре правят уже с Первого Пентиума (1993год).<br><br>&gt; даже обновление BIOS/EFI - уже противозаконно т.к.почти всегда приводит к падению производительности. <br><br>Не противозаконно. Почти никогда не приводят к потерям производительности.<br> <br>&gt; и любого адекватного ПО - поставил и забыл, а не бежать <br>&gt; как белка в колесе за обновленими безопасности попутно читая каждодневно сводки <br>&gt; по троянам и дырам.<br><br>Именно так. Поставил и забыл. Линукс (и Виндос) сами подгружают свежие микрокоды без участия пользователя.<br>А кто отключил обновления - сам себе злобный буратино.<br> https://opennet.ru/openforum/vsluhforumID3/119996.html#197 Wed, 11 Mar 2020 08:28:17 GMT &gt;Всё дело в том что любое упреждающего чтения памяти неэффективно<br><br> Как раз на нем все и держится. Если на каждую операцию взять ячейки один по смещению 1 от указателя и сложить с ячейкой два по смещению 2 от указателя приходилось бы 4 раза ждать память - эффекта от быстрого проца не было бы никакого. Посему во времена оные и перешли на память с большим объемом кешлайна для обмена с процом (сначала по 32, а потом и по 64 байта за прием). Ибо адресовать приходится большой объем памяти (дело пошло на терабайты), а поиск адреса чем он длиннее - тем он дольше.<br>