LINUX.ORG.RU
Ответ на: комментарий от SakuraKun

у тебя просто дистрибутива нормального не было ;-) установи свежий без’SystemD’шный

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

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

Амд мега решето:

Return Address Security https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7005.html

Cross-Process Information Leak https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html

Speculative Race Conditions https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7016.html

Execution Unit Scheduler Contention Side-Channel https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1039.html

Speculative Leaks Security Notice https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7007.html

Cross-Thread Return Address Predictions https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1045.html

IBPB and Return Stack Buffer Interactions https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1040.html

AMD CPU Branch Type Confusion https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1037.html

Speculative Load Disordering https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1035.html

AMD CPUs May Transiently Execute Beyond Unconditional Direct Branch https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1026.html

LFENCE/JMP Mitigation Update for CVE-2017-5715 https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1036.html

Transient Execution of Non-canonical Accesses https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1010.html

Speculative Code Store Bypass and Floating-Point Value Injection https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1003.html

Frequency Scaling Timing Power Side-Channels https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1038.html

Software based Power Side Channel https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7006.html

AMD SMM Supervisor Vulnerability https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7011.html

SMM Memory Corruption https://www.amd.com/en/resources/product-security/bulletin/amd-sb-4003.html

Disrupting AMD SEV-SNP https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3008.html

SEV-SNP Firmware Vulnerabilities https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3007.html

Debug Exception Delivery in Secure Nested Paging https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3006.html

AMD INVD Instruction Security Vulnerability https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3005.html

AMD SEV VM Power Side Channel https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3004.html

Ciphertext Side Channels on AMD SEV https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1033.html

AMD Secure Encryption Virtualization (SEV) Information Disclosure https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1013.html

TLB Poisoning Attacks on AMD Secure Encrypted Virtualization (SEV) https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1023.html

AMD Secure Encrypted Virtualization https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1004.html

fTPM Voltage Fault Injection https://www.amd.com/en/resources/product-security/bulletin/amd-sb-4005.html

TPM Out of Bounds Access https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7002.html

CVE-2021-26373 … CVE-2021-26350 https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1028.html

CVE-2021-26317 … CVE-2021-26382 https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1027.html

CVE-2023-20576 … CVE-2023-20587 https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7009.html

CVE-2020-12930 … CVE-2023-20526 https://www.amd.com/en/resources/product-security/bulletin/amd-sb-5001.html https://www.amd.com/en/resources/product-security/bulletin/amd-sb-4001.html

CVE-2020-12944 … CVE-2021-26338 https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1021.html

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

Да. В-общем, желающие - у кого есть и AMD и Intel пекарни схожей производительности и ~2013 года, могут провести следующий тест: запускаем бенчмарки OpenBenchmarking (которыми пользуется Passmark) - вначале на дистрибутиве с ISO'шника ~2017 года без обновлений (незадолго до обнаружения Meltdown и прочих уязвимостей, но в то же время после того как поддержка железа ~2013 года была вылизана), и на современном дистрибутиве со всеми обновлениями. Даже если вы не будете отключать гипертридинг у Intel'а для второго теста, вопреки опасениям по безопасности, ожидается серьёзный проигрыш Intel'а. я этот тест провести не могу из-за отсутствия Intel'овской машины в настоящий момент

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

Ты тут всего намешал: и чисто райзеновские баги (которые меня не особо волнуют по причине присутствия в Ryzen'е бэкдора AMD PSP) - включая баги в самом этом бэкдоре (реально многовато ссылок с Potential vulnerabilities in the AMD Secure Processor (ASP)), и баги в каком-то TPM (зачем он проприетарный нужен?), и баги в проприетарной версии библиотеки AGESA (у меня в опенсорсном БИОСе коребут таких проблем нету)... Но самое главное, патчи для бОльшей части этих багов не режут производительность в отличие от Intel'а для которого даже гипертридинг вырубать приходится

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

я этот тест провести не могу

Ну т.е. пруфов нету у тебя, одни набросы.

Ты тут всего намешал

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

которые меня не особо волнуют по причине присутствия в Ryzen’е бэкдора AMD PSP

Т.е. ты согласен, что амд решето априори.

баги в каком-то TPM (зачем он проприетарный нужен?

Спроси амд зачем оно запихало его в свою дырявую платформу.

баги в проприетарной версии библиотеки AGESA

Что, не в проприетарной багов нет 100%? Или как у вас там разгон работает без неё?

патчи для бОльшей части этих багов не режут производительность

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

в отличие от Intel’а

Мы же уже выяснили что ты фантазируешь и не проверял.

гипертридинг вырубать приходится

Никто его нигде не вырубал, и это только для старых процессоров.

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

пруфов нету у тебя

т.к. Intel'овского ПК у меня сейчас нет, приходится ориентироваться на пруфы авторитетных издательств вроде Phoronix

Не, я тут принёс исключительно баги дырявого амд

баги нового AMD, особенно уязвимости в бекдоре PSP, меня особо не волнуют. Напоминаю, изначальный предмет нашего спора: твоё утверждение, что старое AMD - ужасные тормоза, даже по сравнению со старым Intel'ом, и делать ничего серьёзного на нём нельзя. Моей многолетней практикой это не подтвержается - и виртуалки параллельно летают и всё работает довольно-таки быстро! Вот я и выдвинул контртезис, что старое AMD быстрее чем ты думаешь + старый Intel с учётом режущих производительность патчей хуже старого AMD; поэтому сидеть на старом AMD - ради повышенной безопасности благодаря опенсорсному БИОСу coreboot и отсутствию бэкдоров ME/PSP - вполне имеет смысл

которые меня не особо волнуют по причине присутствия в Ryzen’е бэкдора AMD PSP

Т.е. ты согласен, что амд решето априори

Новое AMD - конечно, не такое решето как Intel, но его бэкдор PSP (как и ME) - та ещё дырень. Поэтому, когда меня просят подобрать железо для нового компа, я естественно рекомендую AMD, но сам ни одного компа с ME/PSP не имею ;-)

Спроси амд зачем оно запихало его в свою дырявую платформу.

как и в случае с ME/PSP, дурной пример заразителен

Что, не в проприетарной багов нет 100%? Или как у вас там разгон работает без неё?

те баги AGESA, которые ты перечислил, касаются новой проприетарной AGESA. в опенсорсном БИОСе coreboot используется старая опенсорсная AGESA, во многом переписанная. Разгон работает: TurboCore есть, кастомные тайминги оперативки выставляются

патчи для бОльшей части этих багов не режут производительность

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

Если баг например в бэкдоре PSP - с аппаратной точки зрения являющемся встроенным сопроцессором Ryzen'а - то его патч ну никак не повлияет на производительность; аналогично и со встроенным TPM. + Иногда Ryzen'овские уязвимости устраняются при помощи обновления микрокода без потери производительности, пример:

«Уязвимость Zenbleed устранена на уровне обновления микрокода. Для Linux подготовлен патч для загрузки исправленного микрокода. В случае невозможности обновить микрокод имеется обходной способ блокирования уязвимости, приводящий к снижению производительности»

гипертридинг вырубать приходится

Никто его нигде не вырубал, и это только для старых процессоров.

Так ведь старые процессоры прежде всего и волнуют, т.к. в новых есть бэкдоры ME/PSP

Лучше обойтись интелом, у него только Meltdown и то в более старых процессорах.

Только что ведь признал что в старых процессорах и Zombieload :D Осталось остальные 18 признать ;-)

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

авторитетных издательств вроде Phoronix

Посмешил. Или это сарказм?

баги нового AMD, особенно уязвимости в бекдоре PSP, меня особо не волнуют

Какое дело что тебя там волнует, амд подсунули сотням миллионов пользователей решето вместо процессоров. Гнусная конторка.

изначальный предмет нашего спора

Изначальный предмет спора - амд дырявое решето. Ты просто теперь отступаешь к другому тезису в рамках демедж контроля.

старое AMD - ужасные тормоза, даже по сравнению со старым Intel’ом

Конечно, у него -40% IPC, каждый может лично убедиться запустив в браузере mozilla kraken.

делать ничего серьёзного на нём нельзя

Можно конечно кое-что, медленно и уныло, как и в гамаке лорчить можно. Но нафига?

летают и всё работает довольно-таки быстро

Т.е. более серьёзного аргумента чем «мне на глаз в принципе норм» у тебя нет? На глаз и двойную разницу можно прошляпить.

старое AMD быстрее чем ты думаешь

Незначительно.

старый Intel с учётом режущих производительность патчей хуже старого AMD

4.2

поэтому сидеть на старом AMD - ради повышенной безопасности благодаря опенсорсному БИОСу coreboot и отсутствию бэкдоров ME/PSP - вполне имеет смысл

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

Новое AMD - конечно, не такое решето как Intel

4.2 Вон выше тонна амд-специфичных дыр.

рекомендую AMD, но сам ни одного компа с ME/PSP не имею

Ну это классика, обычно амд форсят сами упорно сидя на интеле.

как и в случае с ME/PSP, дурной пример заразителен

Гнусная конторка, в сговоре участвует.

используется старая опенсорсная AGESA

И где пруф что там нет багов, особенно учитывая предыдущий опыт с этим решетом? И как там с поддержкой новых процессоров и всех их фич?

Если баг например в бэкдоре PSP

А чего ты так упорно маневрируешь в сторону psp, 30+ выше запощенных уязвимостей спекулятивного выполнения, виртуализации, управления питпанием слишком неудобны для обсуждения?

Иногда Ryzen’овские уязвимости устраняются при помощи обновления микрокода без потери производительности

Устранение через микрокод не значит отсутвие потери производительности. Обычно как раз наоборот.

Так ведь старые процессоры прежде всего и волнуют

Старые уже никого не волнуют - их массово отправляют на свалку.

Осталось остальные 18 признать

Ты недосчитался - в амд 30+, всякие RetBleed, INCEPTION, Cross-Thread Return Address Predictions…

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

У твоих любимых рисователей в экселе показывают значительную просадку по производительности, не знаю откуда ты выдумал что её нет: https://www.phoronix.com/review/amd-inception-benchmarks/2

И это только один баг из десятков…

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

амд подсунули сотням миллионов пользователей решето вместо процессоров

интел подсунул ещё больше решета, т.к. они намного раньше впендюрили себе проклятый Intel ME - и очень жаль что амуде последовала их примеру. Главный злодей и бэкдоропихатель - именно Intel!

Изначальный предмет спора - амд дырявое решето

Если ты считаешь, что я всерьёз могу топить за железо с бэкдором ME/PSP - то ты ошибаешься; новое x86-64 железо меня мало интересует по причине его забэкдоренности

Можно конечно кое-что, медленно и уныло

Напротив - очень даже быстро, особенно благодаря 16 гигам «игровой» оперативки. Даже прожорливая QubesOS с кучей параллельно работающих виртуалок - и та нормально работает

Т.е. более серьёзного аргумента чем «мне на глаз в принципе норм» у тебя нет?

Сформировалось целое сообщество людей, юзающих коребутный G505S с QubesOS - и всё потому что это самый мощный коребутный ноут без ME/PSP : благодаря AMD A10-5750M, он запросто уделывает интеловские «без-ME'шные» Thinkpad'ы на Core 2 Duo (которые можно считать без-ME'шными лишь с некоторой условностью)

эти печки массово выходят из строя отвалами

Амудешные дискретки HD-8570M / R5-M230, которые стоят в G505S - не отваливаются, процессоры A10-5750M нормально работают, а южный мост A76M Bolton-M3 крайне редко ломается (только на одном из известных мне G505S он был со сломанным CMOS, так что ноут жёстко зависал при попытке сохранения настроек - но в coreboot на G505S настройки вкомпиливаются внутрь, без использования CMOS, так что норм - а в остальном всё прекрасно работало). Так что конкретно эта платформа - вполне себе надёжна

жрут как i9

мобильные i9 - 55 ватт, а тут только 35

А чего ты так упорно маневрируешь в сторону psp,

Ну как бы я уже это много лет делаю ;-) Следует обличать любые бэкдоры - хоть Intel'овские, хоть AMD'шные. Но то, что эта бэкдорная тема пошла с лёгкой руки Intel'а, прощать нельзя

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

Не то чтобы неудобны (у Intel CVE'шек куда больше), просто неинтересны из-за наличия ME/PSP в этих новых платформах, делающих их непригодными для ценителей безопасности

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

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

Старые уже никого не волнуют - их массово отправляют на свалку

морально устарели

Благодаря отсутствию бэкдоров ME/PSP, им и через 10 лет будут пользоваться

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

Главный злодей и бэкдоропихатель

В рамках нюрнбергского процесса прецедент уже разжёван, «последовали их примеру» не отмаза.

Если ты считаешь, что я всерьёз могу топить за железо с бэкдором ME/PSP

Ну ты же его рекламируешь.

Напротив - очень даже быстро, особенно благодаря 16 гигам «игровой» оперативки

Лол, между «хотя бы не зависло в свапе» и «быстро работает» ещё пропасть промежуточных состояний.

Сформировалось целое сообщество людей

Пользователей haiku больше, лол.

не отваливаются

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

а тут только 35

Ну так оно и не перформит хотя бы в половину от ш9.

у Intel CVE’шек куда больше

Что-то не заметил, аж запарился сюда их копипастить.

Для этой баги - потерь по производительности удаётся избежать

Бенчмарки показывают обратное.

и через 10 лет будут пользоваться

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

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

Амд тех времён не чинят даже - сразу говорят нерентабельно

Потому что благодаря модульности (даже проц сокетный) - те матплаты на замену стоят ~3 тысячи да и само железо недорогое, так что ремонтникам проще зарабатывать на ремонтах нового железа - где всё напаяно на матплату которая стоит от 20 тысяч

Выход из строя

не встречал ни одного дохлого амуде, зато дохлых интелов повидал немало

SakuraKun ★★★★★
()