Исследователи из компании Bitdefender выявили (https://www.bitdefender.com/business/swapgs-attack.html) новую уязвимость (CVE-2019-1125 (https://security-tracker.debian.org/tracker/CVE-2019-1125)) в механизме спекулятивного выполнения инструкций современных CPU, которая получила имя SWAPGS, соответствующее названию процессорной инструкции, вызывающей проблему. Уязвимость позволяет (https://access.redhat.com/articles/4329821) непривилегированному атакующему определить содержимое памяти ядра, других процессов или виртуальных машин в системе. Проблема подтверждена (https://software.intel.com/security-software-guidance/insigh...) в процессорах Intel (x86_64) и частично затрагивает (https://www.amd.com/en/corporate/product-security) процессоры AMD, для которых не проявляется основной вектор атаки. Ранее реализованные методы противодействия уязвимостям Spectre и Meltdown не защищают от атаки SWAPGS при использовании процессоров Intel, но для Linux, ChromeOS, Android и Windows уже предложены исправления.Уязвимость относится к классу Spectre v1 и основывается на идее восстановления данных из процессорного кэша, оставшихся после спекулятивного выполнения инструкций. Блоки предсказания переходов современных CPU для повышения производительности применяют упреждающее выполнение некоторых инструкций, которые вероятнее всего будут выполнены, но не дожидаясь вычисления всех факторов, определяющих их выполнение (например, когда ещё не вычислены условия перехода или параметры доступа). Если прогноз не подтверждается, процессор отбрасывает результат спекулятивного выполнения, но обработанные в его ходе данные оседают в процессорном кэше и могут быть восстановлены при помощи методов определения содержимого кэша по сторонним каналам, анализирующих изменение времени доступа к прокэшированным и не прокэшированным данным.
Особенность новой атаки в использовании утечки, возникающей в ходе спекулятивного выполнения инструкции SWAPGS, которая применяется в операционных системах для замены значения регистра GS при переходе управления из пространства пользователя в ядро ОС (используемое в пространстве пользователя значение GS заменяется на значение, используемое при операциях в ядре). В ядре Linux в GS хранится указатель per_cpu, используемый для доступа к данным ядра, а в пространстве пользователя указатели на TLS (Thread Local Storage).
Для исключения двойного вызова инструкции SWAPGS при повторном обращении к ядру из пространства ядра или когда выполняется код, не требующий замены регистра GS, перед инструкцией осуществляется проверка и условный переход. Механизм спекулятивного выполнения заранее переходит к выполнению кода с инструкцией SWAPGS, не дожидаясь результата проверки, и если выбранная ветка не подтвердилась, отбрасывает результат. При этом указанное в регистре GS значение используется в зависимых операциях с памятью и оседает в кэше CPU, даже если это значение некорректно.
В ядре Linux проблема устранена (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) через изменение логики вызова инструкции SWAPGS (блокирование спекулятивного выполнения), по аналогии с исправлением других уязвимостей класса Spectre v1. Предполагается, что добавленная защита минимально повлияет на производительность типовых рабочих нагрузок. Задержка возникает на этапе переключения между пространством пользователя и ядра, что может привести к снижению производительности, например, при интенсивном выполнении системных вызовов из приложения или частой генерации NMI и прерываний.Исправление требует установки обновления ядра как в основной системе, так и в гостевых окружениях, с последующей перезагрузкой системы. Для отключения защиты в Linux может быть испорльзована опция "nospectre_v1", которая также отключает меры для блокирования уязвимости SWAPGS. Исправление доступно в виде патча (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) для ядра Linux, который уже включён в состав выпусков 4.19.65 (https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.65), 5.2.7 (https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.2.7), 4.14.137, 4.9.188 и 4.4.188. Обновления для дистрибутивов Linux пока не выпущены (Debian (https://security-tracker.debian.org/tracker/CVE-2019-1125), RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-1125), Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1738285), Arch Linux (https://security.archlinux.org/CVE-2019-1125), SUSE/openSUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2019-1125), Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2...)). В Windows проблема без лишней огласки была устранена в июльском обновлении (https://portal.msrc.microsoft.com/en-US/security-guidance/ad...). Компания Google подготовила (https://chromium-review.googlesource.com/c/chromiumos/third_...) исправление для ядра 4.19, поставляемого в ChromeOS и Android (https://android-review.googlesource.com/c/kernel/common/+/10...).
По заявлению исследователей из компании Bitdefender, Intel был информирован о проблеме ещё в августе прошлого года. Проблему было решено устранить программно, для чего к скоординированной выработке исправления были привлечены разработчики из Microsoft, Google и ядра Linux. Старые процессоры Intel, до Ivy Bridge, атаковать значительно труднее из-за отсутствия поддержки инструкции WRGSBASE, использованной в эксплоите. Системы ARM, POWER, SPARC, MIPS и RISC-V не подвержены проблеме, так как не поддерживают инструкцию SWAPGS.
Проблема угрожает главным образом обладателям процессоров Intel -
основная техника атаки на системах AMD не проявляется, так как данные процессоры не используют спекулятивное исполнение инструкции SWAPGS. При этом на процессорах AMD удалось воспроизвести неопасный вариант атаки, основанных на извлечении базового значения регистра GS из кэша. Для блокирования данного варианта атаки достаточно (https://www.amd.com/en/corporate/product-security) существующих методов защиты от уязвимостей Spectre v1.
URL: https://software.intel.com/security-software-guidance/insigh...
Новость: https://www.opennet.dev/opennews/art.shtml?num=51234
Что? Опять?!!
> Проблема угрожает главным образом обладателям процессоров Intel
> Проблема угрожает главным образом правообладателям процессоров Intel
А вот обладателям процессоров, набор команд которых доступен только под NDA, угрожает тайность этого набора команд, ведь о дырах будут знать только ограниченное количество обладателей тайных знаний, а обладатели этих процессоров не смогут даже попытаться защититься от уязвимости
а зачем им от меня защищаться, если они на меня же и работают?
noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=offВаши патчи не нужны
Нет ни одного случая взлома
Нет пока ни одного публично известного случая эксплуатации.
А потом через неделю кто то напишет PoC который будет находить ключи от кошельков с помощью скрипта из браузера и оно лавиной накроет всех за следующие две недели.
у меня есть сотни систем, где нет и не может быть никакого браузера, кроме wget - и чо?У меня есть аж две где нет вообще speculative execution - и чо?
"разработчики" не владеют условной компиляцией, но считают что могут всех от всего защитить? Или все же посасывают гранты интела и делают что им велит босс?
> А потом через неделю кто то напишет PoC который будет находить ключи от кошельков
> накроет всех
> всехНе надо выдавать желаемое за действительное. Если криптовалюты запретить, а их пользователей - сажать, но в сми не освещать, то 99.9% населения об этом и не узнает.
Хахах, я тупо ржу минут 20 уже. Интел такая помойка. Дырка на дырке. Они вместо дырок в p-n переходе, делают дырка в процах. Ухахахахах.
Intel делал (и делает) быстрые процессоры. И Вы его за это любили и хвалили.Теперь оказалось, что быть быстрым без хитрых (и немного грязных) трюков не получается. И внезапно Вы начали его ругать.
Заметьте, что скорость одного ядра у AMD и ARM на гигагерц все ещё ниже, чем у Intel (если отключит защиту от всех этих «уязвимостей»)
Вы определитесь, Вам шашечки или ехать?
Я сделал свой выбор: зашёл на makelinuxfastagain и последовал инструкциям.
У АМД с выходом Zen2 скорость одного ядра на гигагерц уже выше чем у процессоров Ител, посмотрите в интернете полно тестов на одной частоте, разница лишь в том что Интел может достигать 5 гигагерц в разгоне, а АМД нет.
В однопотоке всё ещё уступают конкуренту, но уже настолько чуть, что этим, лично я, могу пренебречь. В многопотоке претензий нет, а с учётом цены - я бы смотрел именно в сторону AMD.Дабы не быть голословным: https://3dnews.ru/990334/
на равных частотах не уступают..
https://forum.ixbt.com/topic.cgi?id=8:25749:22199#22199Если кратко - очень ангажированный обзор.
>Заметьте, что скорость одного ядра у AMD и ARM на гигагерц все ещё ниже, чем у Intel (если отключит защиту от всех этих «уязвимостей»)Скорость в попугайчиках и тестов, написанных и оптимизированных под Intel?
Я понимаю, когда удельная производительность измеряется в расчете на доллар цены или на ватт потребляемой мощности. Но какой смысл в измерении в расчете на гигагерц? Гигагерцы сами по себе ресурсом не являются. Давайте еще мерять производительность на килобайт кеша, на контакт сокета или на одну команду из общего количества поддерживаемых процессором.
Разогнать частоту проще, чем ipc.
"измерении в расчете на гигагерц? Гигагерцы сами по себе ресурсом не являются."Гигагерцы -это время. Если Ваше время ничего не стоит и ресурсом не является, то у меня для вас две плохих новости.
> Гигагерцы -это время.Гигагерцы - это не время, а внутренняя характеристика процессора, которая уже давно мало что значит.
И рядового пользователя должны интересовать такие показатели, как общая производительность, производительность на доллар, производительность на ватт. А сколько там в нём гигагерц - пусть инженеры обсуждают.
> общая производительность, производительность на долларТех кого это интересует, используют все больше мейнфреймы. Протирают их тряпочкой, и дальше используют.
То-то "Восход" съехал с айбиэмовских шкафов на эльбрусы, присовокупив к этому, что денег ушло примерно столько же, сколько синим за год полагалось отстёгивать только на поддержку...
Так их на рубль интересует, не на доллар.
Дело в том, что дыры Эльбруса не принято озвучивать публично, у нас всё и всегда должно быть ОК. Как оно на самом деле обстоит всем давно ясно. дыры как всегда прикрывают плакатами о наших великих достижениях и передовых технологиях (кавычки в словах расставьте сами).
> Дело в том, что дыры Эльбруса не принято озвучивать публично,
> у нас всё и всегда должно быть ОК.Исследуйте, публикуйте. Интел вон и рад бы жить по-прежнему, полагаю, да приходится теперь впереди паровоза если не бежать, так по крайней мере изображать бег.
А можно подробности.
Какие именно задачи эксплуатируются.
Какая была конфигурация IBM, какая сейчас.
И пускай не подробная статистика перфоманса, но хоть какие-то оценки реально применения.
> А можно подробности.Это лучше glebfm@altlinux спросите напрямую. Если не к спеху -- вероятно, он что-нибудь расскажет про p9 на ppc64le в Калуге на нашей конференции в конце сентября: https://www.basealt.ru/about/news/archive/view/xvi-konferenc.../
Частота - это величина обратная времени.
Один герц - это единица делёная на секунду.
Поэтому гигагерцы ну никак не время. Даже наоборот.
> Вы его за это любили и хвалилиЛично я - не любил и не хвалил. После первых P4 ушёл на AMD и бол ше не возвращался.
Но ткнуть носом фанбоев Интела в те помои, которыми они поливали AMD - за это тебе решпект.
Говоря "вы" вы подразумеваете "я". Посему: к чему здесь это ваше раскаяние здесь? Поплачьте, полегчает.
Ну да, вообще зачем заморачиваться с безопасностью? Главное - чтобы быстро было.Всем головным мозгом надо работать при проектировании процессоров, а не только его функцией алчности. Тогда будет возможно ехать с хорошей скоростью, без всех этих дыр впридачу.
Если вас лично устраивает сидеть на быстром, но дырявом железе - да на здоровье.
Мой выборnoibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off
Я тоже сделал свой выбор и свалил на ам4 сразу после выхода. :)Быстрота интелов нынче только за счёт гигагерцов и конского потребления, ну и в отдельных синтетических бенчмарках про кеш и память они лучшие.
По КПД на Ватт интел уже не лучший, даже если заплатки отключить.С интела мне импонирует хоть как то 2500 и соседние с припоем, если бы я тогда их купил то так бы и сидел на них, а вот коредуо мне уже тесноват был - часто приходилось смотреть кто там что жрёт, да и собиралось всё долго.
ARM - да, я тоже не видел чтобы там ядра производительными были, хотя снапдрагон 835 уже похож на что то на чём можно жить, по крайней мере из рекламных буклетов это так выглядит.
А насчёт AMD - ты заблуждаешься, до райзена ничего хорошего и правда не было, теперь же уровень примерно одинаковый: где то один лучше, где то другой.
Учитывая сколько гемороя нынче интел доставляет: частая смена сокета, заплатки, паста под крышкой - я даже хз. У меня вон на плату с 3хх чипсетом последний проц легко встанет и будет работать.
можно заменить одним параметром "mitigations=off"
Если читать документацию kernel.org
Это вроде работает только на последних ядрах (с 5.1 что ли). Если на какой-нибудь 4.15 не бекпортировали, то там придётся писать всю портянку параметров для индивидуального отключения.
с 5.2 ядра
https://www.opennet.dev/opennews/art.shtml?num=51051
Время валить на ARM
Если single-thread производительность не интересует, то и на RISC-V можно. Или на PIC16. Или даже на AVR.
на рассыпуху сразу, чё мелочиться
Пробовали на элементах И-НЕ джаваскриптовый движок реализовать?
О, будет повод выкинуть уеб-технологии во главе с жабоскриптом!
Зато Electron тормозить не будет =D
И работать тоже не будет...
Power. Талос2 и К.
Если цена не интересует, то лучше System Z.Да и с той же самой single-thread производительностью у Power все не лучшим образом обстоит. В виде самосвала оно имеет свои преимущества, из-за работы с памятью в том числе, а вот по пробкам гонять лучше Intel.
Ох уж эти интелофаны со своей однопоточной производительностью... В 2019 году, ага. Гордится-то больше нечем, а шерето дырявое за многабабок надо оправдывать.
В 2019 году даже nodejs умеет в несколько потоков - один поток для кода, пул потоков для IO. Но у интелофанов ещё 2004 год не прошёл.ЗЫ: имею 9700К, посылаю лучи поноса эпплу за то, что нет в их линейке устройств на АМД процессорах, чтобы я мог запилить нормальный хакинтош (без всяких патченых кернелов) на АМД.
Как будто это что-то меняет. Производительности тому потоку что для IO не нужно, его и самого было бы не нужно если бы Linux умел в асинхронность. Остается тот поток что для кода, которому нужна все та же single thread производительность.
> Производительности тому потоку что для IO не нужно.Это зависит очень сильно от проекта. У меня на ноде есть проект, в котором 40% процессора отжирает именно IO, так как вычислительной нагрузки на джаваскрипт практически нет.
Что-то вы неправильно делаете, товарищи. Ниже по треду СУБД в CPU упирается, у вас - IO отжирает 40% процессора. Если вычислительной нагрузки нет, то "бери больше, кидай дальше" поручается DMA и буферу сетевой карты.
>Да и с той же самой single-thread производительностью у Power все не лучшим образом обстоит.Зато по восемь потоков на ядро тянет
> Зато по восемь потоков на ядро тянетЭто на сервере хорошо, или Gentoo собирать.
Ну почему, для сборки альта тоже пригождается:http://git.altlinux.org/tasks/archive/done/_228/233651/logs/...
http://git.altlinux.org/tasks/archive/done/_228/233632/logs/...
http://git.altlinux.org/tasks/archive/done/_228/233692/logs/...:)
Это в "на сервере".
> Да и с той же самой single-thread производительностью у Power все не
> лучшим образом обстоит. В виде самосвала оно имеет свои преимущества, из-за
> работы с памятью в том числе, а вот по пробкам гонять
> лучше Intel.Тама вроде как до 4-х потоков на ядро, если я ничего не путаю из прочитанного :). Чего вы мне своей однопоточной производительностью тычете, я ДОС-ом давно не пользуюсь на своих используемых телегах.
С DOS или без DOS вся данная пользователю на десктопе в ощущениях производительность упиралась, упирается, и будет упираться в single thread performance.
Да ну блин, я тут немного комплексовал по поводу расходов на эльбрусы, но по сравнению с ценами на полосатиков "в Багдаде всё спокойно" :)Правда, тягаться с ними не очень получается и у x86_64.
> Да ну блин, я тут немного комплексовал по поводу расходов на эльбрусы,
> но по сравнению с ценами на полосатиков "в Багдаде всё спокойно"
> :)
> Правда, тягаться с ними не очень получается и у x86_64.Михаил, вы как лицо, таки имеющее доступ к сиим мифическим для многих железкам - просветите, они наглухо приваренные к плате или таки есть варианты съёмные? :)
https://www.opennet.dev/opennews/art.shtml?num=51228
Большинство ARM подвержены разным вариантам Spectre и некоторые Meltdown. Ни тому, ни другому не подвержен, разве что, Cortex A53. Но для десктопа он, как бы, слабоват.
в нем тоже есть спекулятивное выполнение.Просто искать в нем специфические команды, имеющие побочные эффекты - никому нафиг неинтересно, поскольку все данные с вашего телефона и так уже сперли гугль и его приближенные.
Валите на 486, могу продать один экземпляр. Дорого, надежно!
>Валите на 486, могу продать один экземпляр. Дорого, надежно!На лоре напиши. Там как раз персонаж один резвится, с точно такой логикой.
Я лучче DMP VESA возьму Тот же 486, только разогнанный и холодненький.
o, свежие пирожки подоспели
> Для отключения защиты в Linux может быть испорльзована опция "nospectre_v1"настоящие мужики используют mitigations=off
Если Javascript отключен, то почему нет.
И на каком десктопе он отключен? Браузера lynx хватит всем?
Ну да, если исключить возможность выполнения внешнего кода, то для локалхоста вполне себе решение. Бэкпортировали бы еще эти ваши mitigations=off хотя бы на пару lts веток ядра назад, иначе такими темпами GRUBу скоро потребуется отдельный парсер для импорта списка всех вариантов спектромельдониев в параметры загрузки.
Для кровавых интерпрайзов выбора мажду рeшeтoм и тыквой не стоИт, юзер не мамонт, юзер апгрейд оплатит.
> если исключить возможность выполнения внешнего кодаJavascript.
И? Без жлобоскрипта, по твоему, жизни нет?
> Бэкпортировали бы еще эти ваши mitigations=off хотя бы на пару lts веток ядра назадЕго бэкпортировали, он есть в ядрах: 5.2, 5.1.2, 5.0.16, 4.19.43, 4.14.119, 4.9.176. В changelog'ах к этим версиям об этом написано.
Действительно, так и есть. Благодарю за инфу! Changelog'и просматриваю нерегулярно, каюсь. Проверил на 4.19 - отключает все, за исключением заплаток микрокода, pte inversion и user pointer sanitization.
Интересно, сколько вся эта музыка (в смысле патчи в ОС от уязвимостей в процах) уже отъедает от скорости работы ОС?
мы запретили вам это мерять!
Немедленно уберите и прекратите!
Не знаю, но два года назад мой комп работал ощутимо быстрее, и дело не в веб-разрабах. Надо попробовать старый дистр запустить.
а у меня прям сердце разывается, когда из-за этих заплаток мой 4х поточный ультрабук стал 2х, и скорость ссд упала в 2 раза, вот это нифига не смешно.
Последний раз, когда интересовался результатами тестов, средняя суммарная просадка на камнях sandy/ivy/haswell доходила до 30%, iops на твердотельниках при интенсивной записи терял все 40. А было это еще до запиливания фиксов l1tf/foreshadow. Такие дела.
Все зависит от режима. Но тут стоит ориентироваться на усреднённые значения. Для Sandy/ivy 14% в режиме auto.
Спецслужбам раздолье.
> Проблему было решено устранить программно, для чего к скоординированной выработке исправления были привлечены разработчики из Microsoft, Google и ядра Linux.Не удивлен отсутствию OpenBSD в списке
Неуловимый Джо в списке отсутствует.
Просто в опёнке ещё два года назад уязвимость закрыли :D
С формулировкой "Not a bug"?
Это потому, что об OpenBSD просто никто не вспомнил. Никому не интересна ОС стоящая на трех компах в мире. Так же никто не вспомнил о Хайку, РекталОС или МинетОС, потому что они каждая стоят на одном компе в мире
Нет, их теперь не уведомляют, чтоб не сливали преждевременно
Вы уверены что мужчина который к вам приходит устанавливает ОС, а не пользуется вашей наивностью.
Фикс в работе, патч прямо сейчас проходит ревью.
Для домашнего ПК за роутером - это всё актуально?
Какая разница браузеру, за роутером он или нет, грузить JS с эксплойтами?
только в Firefox снизили точность таймера и запретели SharedArrayBuffer (чтобы нельзя было сделать такой высокоточный таймер самому)а хром как всегда отличился
Note that SharedArrayBuffer was disabled by default in all major browsers on 5 January, 2018 in response to Spectre. Chrome re-enabled it in v67 on platforms where its site-isolation feature is enabled to protect against Spectre-style vulnerabilities.
> только в Firefoxа еще браузеров дофига и больше
А на Эльбрусе работает?
эльбрус уже продают в Мвидеа?
Нет, в Эль Брусе нет предсказателя ветвлений и спекулятивного исполнения.
> в Эль Брусе нет предсказателя ветвленийровно как и практически нет и самого Эльбруса :-)
Не припоминаю в его системе команд такой инструкции.PS: мне вот что интересно -- когда искромётные шутники про цены-магазины и на этом фронте получат логическую затычку для досужего рта, на что они переключатся? (ну, "хвосторезы" же)
PPS: не "если", а "когда" ;-) -- https://sdelanounas.ru/blogs/122600/
Ну можно например про закладки в компиляторе погадать ;) При чем от ЦРУ, ведь движок компилятора разработан американской компанией Edison Design Group, верно?
у нас, конечно, бюджет большой, но ТАКОЙ хренью мы не занимаемся.
Та що ви говорите! А в прошлых тридах осведомленные анонимусы писали, что конпелятор нагло украден известно у кого, поэтому и не показывают.>движок
Фронтэнд, ни?
>>движок
> Фронтэнд, ни?Да: http://altlinux.org/эльбрус/lcc#фронтэнд
Скорее всего никогда.
С 300к руб он врядли до 30к руб опустится, а дороже его точно никто не возьмёт.
Я бы сказал что у него есть шансы стать массовым при ценах до 20к руб - те где по себестоимости железа аналогичной производительности от конкурентов.Потом там же только ваши унылые полтора линукса, даже убунты нет нативно.
Те это очень на любителя всё.
Скажем я бы себя не уговорил такое купить даже за 50к руб, потому что мне проще за эти деньги взять райзен на 12-16 ядер и не иметь проблем с софтом, что называется поставить и получать удовольствие.
> С 300к руб он врядли до 30к руб опустится, а дороже его
> точно никто не возьмёт.По текущим слышанным мною оценкам -- при партии в 10 тыщ машин розничная стоимость 801 может добраться до ~80 т.р., 101 -- до ~50. Сильно ниже -- это, звыняйте, уже миллионные тиражи нужны, не всё сразу.
При этом 801 -- это неплохая рабочая станция, а вот в сегмент "массовым до 20" может пойти что-то вроде 2с3, но не раньше 2021, как мне кажется...
Миша, это не продавабельно даже за 30, даже если там будет 16-64 ядра.
Я думаю что даже за 20к руб 801 или какие там топовые будут крайне мало брать, ибо интересно только энтузиастам.
Чтобы оно пошло в масс сегмент нужно ещё много чего сделать, в том числе и какуюнибудь убунту туда впилить, чтобы можно было поставить и быть увереным что это не гос линукс от майора.
Ну или вон транслятор + венда, но такая производительность мало кому интересна.
> Я думаюЯ думаю иначе; ну а жизнь покажет, как обычно.
А как такое продавать обычным людям?
Любое честное сравнение с х86 по скорости, цене и совместимости с софтом и железом он начисто сливает.
Остаётся только что он практически наш полность и что в нём вроде как всё более безопасно. Но это не точно. :)Мне, как энтузиасту, он не нужен потому что:
- сильно дорого
- эти знания никому не продать в мире (как и 1с)
- там пилить и пилить софт, фрю туда никто не портировал а самому долгоДля обучения проще взять тот же арм в пайнбуке у китайцев за 100 баксов и ловить кайф, потому что половина как минимум уже работает сразу, остальное немножко допилить и будет почти ноут, уж терминал точно.
Или вон RISC-V вроде перспективная, там хотя бы живых разрабов больше.Чтобы эльбрус перешёл из попильной темы в разряд живых нужно:
- запихать его во все вузы и школы
- проводить какие то мероприятия и дарить как приз
- вкладыватся в PR
- ронять ценники и делать всё чтобы его могли позволить себе взять вторым компом
- открывать доки и исходники
Тогда, может лет через 5 появится живое коммунити энтузиастов которое что то будет пилить и тп.Но это всё сложно и не факт, потому что у нас за пределами столиц и нескольких региональных центров с техническими кадрами вообще никак, там даже эникеев толковых практически нет.
> Чтобы эльбрус перешёл из попильной темыКстати, всё хотел спросить: Вы уже перестали бухать по утрам? :)
PS: сказанное _по существу_ -- разумеется, поддерживаю. А вот эти идиотизмы уже немножко надоели.
PPS: pinebook точно щупали? (я -- да)
Отключать гипер трединг научились. Когда можно будет отключить спекулятивное выполнение команд? Оно прироста производительности-то почти не даёт, так, смех один. А проблем целая гора
>Оно прироста производительности-то почти не даёт, так, смех один. А проблем целая гораОткуда вы, такие жЫрные, берётесь вообще?
Что тебе не понравилось? 40% производительности - это ерунда. Процессор 2019 года будет работать на скорости процессора 2014 года. На таком компьютере Ведьмак летал, Драгон Эйдж и кризис. Лично я готов пожертвовать 40% производительности ради безопасности. Это лучше, чем 10-12 защит и антивирус, которые примерно столько же и съедят
Это в твоём специальном случае ограниченной нагрузки. Если же ты попробуешь, скажем, что-нибудь посчитать, или пересобрать систему, то -40% времени будет означать, что система будет за час делать то же, что она могла бы сделать за 36 минут.А антивирусы не нужны -- они только процессорное время с памятью отъедают, и вполне заменяются юблоком с юматриксом и вдумчивым отношением к кликам мышкой.
ок, лично я (хотя соинвесторы и не одобряют) готов тебя в этом поддержать - просто ты пойдешь с работы не в 6, как привык, а в 12. Ночи, ночи, родной.Когда выполнишь на тормозном компе всю ту же работу, которую выполнил бы на быстром за обычный рабочий день.
И не надо мне кивать на 2014й год, а то я тебе еще и зарплату сделаю как в 2014м году.
Главное что первым новостям о данном классе уязвимости уже несколько лет.
А производители узнали о них еще сильно раньше.
Но! Ни Intel ни AMD не предложили новый класс процессоров закрывающих эти проблемы на аппаратном уровне полность. А сколько нам рассказывали как нам нужно UEFI и какое оно безопасное. Ага, дырявая безопасность.
UEFI нужно не нам, а им...
И кто им денежки на новую разработку даст? Тем более разработка процесс не быстрый. Пока разрабатывают выпускают старые архитектуры.
Хз как там у интела, а у амд после выхода зен1 уже пилился зен3 или зен4, ихний архитектор сам сказал в интервью.
Сейчас вот зен2 вышел, каких то фиксов в железе можно ожидать к зен 5 и позднее.
Полагаю у интела тоже длинный временной цикл разработки.UEFI - оно скорее про удобство.
>ихний архитектор сам сказал в интервьютипичный фанат АМД
>ихний архитекторЗена уже давно работает в Интел.
А когда обнаружится, что в Интеле есть блок определения синтетических тестов и спецблок проца, чтобы этот блок крутить и красивые результаты выдавать... Вот тут начнётся настоящее веселье.
Давайте уломаем фороникс, чтоб начали компиляцию ядра для бенчмарков юзать. Пускай интел запилит процессор со спецблоком для ускорения GCC.
у амд был такой — из-за него gcc не работал
>А когда обнаружится, что в Интеле есть блок определения синтетических тестовНазывается блок спекулятивного предсказания. Собственно он и отвечает за то, что инструкции с двумя обращениями к таймеру и вычислением разницы никак не завязаны с тем что происходит в цикле, а значит их можно выполнять независимо. а потом "отбрасывать" если что.
Не, я про другой блок, типа отдельного ядра, со своими способами доступа и работы с памятью.
>Обновления для дистрибутивов Linux пока не выпущеныи
>В Windows проблема без лишней огласки была устранена в июльском обновлении.
На сервер что чаще ставят? На первое, а чего не готово ВСЕ ЕЩЕ? А!... наверное другим заняты - переписыванием)))))
В Линукс "нельзя" сразу фиксы ввозить, потому что это сольет казалось раньше времени, а в вантуз можно, ибо проприетарный кал.
Много у тебя серверов то произвольный код выполняют?
А ну это локальная уязвимость, беспокоиться прежде всего нужно облачным провайдерам, на десктопе можно не заморачиваться
Блин, я опять ничего не понял... Откуда они все это знают, блин??)
Intel инфу занес, что-бы сделали еще -50%, а то хомячки новые процы с 2013го года перестали покупать. Был i7, после патчей стал 8ми поточный pentium II, пора обновлять. Разницу от негативных новостей в курсе акций подкорректировали ценой на новых процах.
>Был i7, после патчей стал 8ми поточный pentium II20 лет интел втирала лапшу в мозг.
Нах штеуда. Мы все сервера переводим на эпики. Частота эпика ниже, но производительность однопотока компенсируется отсутствием патчей с -40% в постгри. + 8 ядер в подарок.
Интересная у вас архитектура, если DBMS упирается в CPU.
1Cный высер vs postgresql. При ~200 select пользователей проц превращается в чайник
> но производительность однопотока компенсируетсянадеюсь тут говорится про производительность на один ватт тепла, а не на единицу доллора процессора
не всем интересно бороться за свои деньги с глобальным потеплением - некоторые вполне могут себе позволить спалить больше ваттов, но сэкономить на цене процессора.
Осторожно, для эпиков, по некоторым данным, до сих пор не всё ладно с таймерами в ядре (и да, мы не просто так озадачились это выяснять, хотя на нагрузочных тестах в Дрездене не вылезало).
Кто нибудь считал после всех патчей снижение производительности случайно уже не превысило 100% ?
Пока нет, но мы работаем над этим
Быстрей работайте, из облачных провайдеров только Microsoft еще не занялась в открытую разработкой свобственных CPU.
да бросьте вы, ничего они не наразрабатывают
Apple вот уже ненаразрабатывал.Но не сразу, конечно. Пока и AMD сгодится для выбивания из Intel скидок.
> (Reuters) - Advanced Micro Devices Inc (AMD.O) on Wednesday released the second generation of its processor chip for data centers and said that it had landed Alphabet Inc’ Google and Twitter Inc as customers.
> Intel shares were down 0.6% to $46.42 in after-hours trading after AMD’s customer announcements. AMD shares were up 0.3% to $29.30.
Когда производительность процов станет отрицательной, можно будет творить удивительные вещи: восстанавливать данные из хэшей, путешествовать в прошлое и многое другое. Только осторожнее, не схлопните всю вселенную.
На Zen 2 все нормально и это главное. Никогда не покупал процессоры Интел, а сейчас еще больше причин игнорировать этого производителя.
Всегда покупал интелы (с 2к года) и никогда не покупал амд (иногда для посмотреть).
С выходом ам4 - перешёл не неё почти везде.
https://make-linux-fast-again.com/noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off
Не нужны никому эти патчи безопасности
Нет ни одного случая взлома
Хотите тормоза - патчите
вообще-то главная беда с этими уязвимостями - что никакого "взлома" и не происходит - просто твои данные, ключи, пароли - утекают левому чуваку, совершенно не оставляя тебе на память следов.
Только небольшой локальный перегрев системы.Но да, в большинстве случаев либо некому и нечего тырить, либо этот некто уже и так локальный юзверь, и ему проще получить рута через одну из миллиона обычных уязвимостей (если он уже не рут или не тот пользователь, которому и так штатно доступны все секретики), чем месяцами перебирать кэши.
Ну и насчет "никому" ты не совсем прав - надо же как-то впаривать новые более дорогие камни...
> главная беда с этими уязвимостямиСамая главная беда с этими уязвимостями состоит в том, что за все в этом мире надо платить!
Хотел побыстрее, "заплати" (сразу видно, что стало побыстрее ;) И тут уж ничего не поделаешь, на то и делали, что бы стало побыстрее. Замедляйте, рандомно!
лан с интелОм ясно, а чё с амде об'зните на пальцах, плз, а то не пнятно в чем засада