The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Линус Торвальдс поднял вопрос целесообразности расширенной защиты от Spectre v2

20.11.2018 09:48

Линус Торвальдс предложил пересмотреть механизм активации патчей STIBP (Single Thread Indirect Branch Predictors), предлагающих дополнительную защиту от проявления уязвимостей класса Spectre v2. Данные патчи недавно были включены в находящуюся в разработке ветку 4.20 и бэкпортированы в стабильный выпуск 4.19.2. При применении STIBP в текущем виде пользователи отметили существенное снижение производительности выполнения некоторых приложений при применении технологии одновременной многопоточности (SMT или Hyper-Threading).

Так как падение производительности достигает 50%, по мнению Линуса, применение STIBP в текущем виде лишено смысла, так как проще и надёжнее вообще отключить SMT/Hyper-Threading, что обычно и делают люди, озабоченные безопасностью. Возникает вопрос, нужно ли включать STIBP по умолчанию, когда у тех, кому действительно важна безопасность, SMT/Hyper-Threading уже отключен. Для обычных пользователей потеря производительности в 50% является существенным фактором и возникает сомнение, стоят ли данные потери блокирования теоретической уязвимости.

Линус считает маловероятным появление практических атак на базе Spectre v2, так как в обычных пользовательских системах основной целью атаки являются браузеры, которые уже добавили защиту на своём уровне (угроза остаётся для изолированных процессов с JIT, для которых может быть выработан метод выборочной защиты). Предлагается по умолчанию использовать только методы защит от Spectre, не приводящие к большому падению производительности, а дополнительные методы применять выборочно или в виде опции.

Арьян ван де Вен (Arjan van de Ven) из компании Intel рассказал, что Intel и AMD не рекомендуют применять STIBP по умолчанию, так как данную функциональность можно сравнить с очень тяжёлым молотком, который не используется в повседневной работе, но необходим при определённых обстоятельствах. Предложенный в обновлении микрокода механизм STIBP позволяет через установку специального бита в регистре CR0 управлять отключением кэшей процессора, что следует делать не повсеместно, а только в особо критичных ситуациях. Тим Чен (Tim Chen) из Intel предложил для выборочного блокирования атак на sandbox включать STIBP только при явном запросе через prctl или для процессов, запрещающих создание core-дампов памяти (PR_SET_DUMPABLE), таких как sshd.

Что касается падения производительности при применении STIBP-патчей в ядре 4.20, то результат очень сильно зависит от вида нагрузки. Например, тестирование в пакете SpecInt Rate 2006 показывает уменьшение пропускной способности на 21%, а тесты Phoronix демонстрируют снижение производительности от 3 до 20%. Инго Молнар (Ingo Molnar), известный разработчик Linux ядра и автор планировщика задач CFS, комментируя ситуацию, предложил сделать обязательным отражение в списках изменений сведений о тестировании производительности при добавлении любых механизмов обхода проблем.

  1. Главная ссылка к новости (https://www.theregister.co.uk/...)
  2. OpenNews: Семь новых атак на механизм спекулятивного выполнения в CPU
  3. OpenNews: Уязвимость в SMT/Hyper-Threading, позволяющая определить ключи шифрования чужих процессов
  4. OpenNews: Грег Кроа-Хартман раскритиковал поведение Intel при исправлении уязвимостей Meltdown и Spectre
  5. OpenNews: В OpenBSD добавлен код программного отключения SMT (HyperThreading)
  6. OpenNews: Два новых варианта уязвимости Spectre. Усиление защиты Chrome
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/49636-spectre
Ключевые слова: spectre, linux, kernel
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (193) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Fracta1L (ok), 10:38, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +61 +/
    Хорошо, что Линус на редкость адекватный человек, в отличие от параноиков-истеричек.
     
     
  • 2.6, Параноикистерик (?), 10:53, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Дайте нам (не)спокойно истерить!
     
     
  • 3.11, iv (?), 11:02, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +14 +/
    > Дайте нам (не)спокойно истерить!

    Истерите пожалуйста, но не в коде ядра.

     
     
  • 4.156, Аноним (156), 19:02, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Вы ущемляете права паранои^W людей с отличающейся подозрительностью и истери^W людей с отличающейся социальной реакцией! Может, вы еще хотите, чтобы проектами руководили компетентные люди?
    (Это все сарказм, если что).
     
     
  • 5.228, голос_Геенны (ok), 17:24, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > (Это все сарказм, если что)

    Не такой уж и сарказм в контексте данного ресурса.

     
  • 2.7, Аноним123 (?), 10:57, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вся суть этих уязвимостей в том, что их трудно обнаружить. Открываешь браузер на какой нить сайт, а он ворует твои данные впн соединений.
     
     
  • 3.25, Fracta1L (ok), 11:26, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Не так. Вот как надо:

    Открываешь какой-нибудь чорный-чорный сайт, а там чорный-чорный эксплоит ворует твои зелёные-зелёные деньги!!!11111111РАС

     
     
  • 4.100, Андрей (??), 13:46, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А что если обычный белый-белый сайт кто-то тихо взломал? Причём для этого достаточно просто получить виртуальную машину на том же хосте, что и белый сайтик.
     
  • 4.108, iPony (?), 14:44, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так-то смех смехом, а практика не смешная на самом деле.

    https://blog.mozilla.org/security/2015/08/06/firefox-exploit-found-in-the-wild

     
  • 3.130, Аноним (130), 17:05, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Можно подумать что эта защита 100% панацея. Есть ещё куча уязвимостей, в том числе софтварных, но о них почему-то все забыли. А ещё забыли как впилили в веб вебассембли и прочий шлак, который добавил ещё миллион уязвимсотей.
     
     
  • 4.139, Аноним (139), 17:31, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Но софтверные уязвимости хоть устранять можно на порядок меньшими потерями.
     
  • 4.178, Аноним (178), 21:36, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Сколько же вы, дeбилы, будете пугаться wasm только потому, что это страшное слово сильно отличается от привычного, но не менее "опасного" asm.js?

    По факту - те же яйца, только сбоку. Дизассемблируй wasm и получи ту же читабельность (на самом деле даже большую) чем asm.js!

     
  • 4.197, neit95 (ok), 02:10, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А ещё в браузеры когда-то добавили js, который добавил миллион уязвимостей. Да и вообще, когда-то изобрели компьютер, из-за которого появились все эти уязвимости. Как же хорошо было без компьютеров, правда?
     
  • 3.198, Аноним (198), 02:16, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В браузерах отдельные защиты реализуются
     
  • 2.64, Аноним (64), 12:27, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >Линус на редкость адекватный человек

    Звучит как "пишешь вам патчи, пишешь, занимаешься неблагодарным делом, так оно ещё и в половину медленней становится, f*** you intel & users"

     
     
  • 3.135, Аноним (130), 17:20, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А потом на конференции: "So Intel, fuck you!".
     
     
  • 4.200, _ (??), 02:45, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Забудь!
    Линуса же на ковёр вызывали ... он теперь CoC-нутый и не торт энимо :)
     
  • 2.172, Onanon (?), 21:18, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Хорошо, что Линус на редкость адекватный человек, в отличие от параноиков-истеричек.

    Занятно, но поступил он в итоге также как "параноики-истерички" - предложил отключать HT тем, кому это важно.
    Одна и та же мысль, высказанная Тео и Линусом у опеннет-линуксоидов вызывает противоположные реакции. Как же так?
    Может это не Тео и команда - онанирующие на безопасность обезьяны, а линуксоиды - онанирующие на Линуса невежды?

     
     
  • 3.175, Fracta1L (ok), 21:22, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Ты что-то путаешь, параноики-истерички не смотрят, нужно это кому-то или нет, они бегают по форумам и визжат, что всё пропало, и срочно нужно всё отключать, заколачивать патчами, или вообще переходить на сверхсекурные архитектуры, а если тебе это не нужно, то ты тупой хомяк. Вот это как раз онанирующие на безопасность обезьяны.
     
     
  • 4.193, Onanon (?), 00:40, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    В таком случае, параноиков-истеричек не наблюдается вовсе Чинить узявимости, бе... большой текст свёрнут, показать
     
     
  • 5.194, Аноним (194), 01:34, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Напомни-ка: что он там такого особенного внедрил чтобы, например, ХертБлид бэкдор не сработал?
    Подсказать? --- Ни-че-го.
    Ну только на сферических конях в вакуумах тормозной и никому ненужный OpenBSD и может отыгрываться...
    Что-то он там где-то от кого-то услышал что гипертрединг надо отключать и вот уже даёт все "советы от супер-хакера", т.е. от себя лично

    Напоминает такие же тупые "советы от гуру" по оптимизации винды, которые копировались (и копируются до сих пор) по всем интернетам, типа: "выставите вручную размер файла подкачки в полтора раза больше чем есть оперативки потому что винда 98 плохо умеет выбирать размер, то ли дело мы!!!!" или "поставьте виртуальный RAM-диск и туда поместите файл подкачки чтобы ускорить систему!"

     
     
  • 6.218, нах (?), 10:24, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ну только на сферических конях в вакуумах тормозной и никому ненужный OpenBSD

    ничего что ненужно-openbsd и ее поделка libressl пострадала от ВСЕХ уязвимостей следом за heartbleed? (не считая какой-то малопонятной мелочи, как обычно, срабатывающей только в сферическом вакууме при настройках, сделанных засланными шпионам)

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

    > или "поставьте виртуальный RAM-диск и туда поместите файл подкачки чтобы ускорить
    > систему!"

    так это ж правильный совет - мы ж заимплементили это в виде zram! ;-)

     
     
  • 7.223, Onanon (?), 16:09, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > ничего что ненужно-openbsd и ее поделка libressl пострадала от ВСЕХ уязвимостей следом за heartbleed?

    Ничего, что libressl появился как ответ на heartbleed в openssl?
    Но ты продолжай, не все лужи ещё газифицированы.

    > там могут быть очень-очень интересные дырки

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

     
     
  • 8.226, нах (?), 17:10, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ничего ты бы читать поучился - или хотя бы головенкой думать что они это умею... большой текст свёрнут, показать
     
     
  • 9.252, Аноним (-), 02:45, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну я бы так не сказал Тео Де Раадт ведь пропиарился и денег собрал на ешё одну н... текст свёрнут, показать
     
  • 6.224, Onanon (?), 16:12, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Напомни-ка: что он там такого особенного внедрил чтобы, например, ХертБлид бэкдор не сработал?

    А кто внедрил-то?
    Вот тот-то и оно-то. А сейчас Тео меры принял, Линус оподливился и повторил за Тео.
    Зачем ты принёс свой хертблид, ты что, не понимаешь, в чём разница ситуаций?
    Или ты думаешь, что есть хоть кто-то, предвосхитивший в своём коде все будущие потенциальные проблемы в безопасности?

     
  • 5.209, Fracta1L (ok), 07:42, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > В таком случае, параноиков-истеричек не наблюдается вовсе

    Ясно, понятно XD

     
  • 3.230, freehck (ok), 18:35, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Занятно, но поступил он в итоге также как "параноики-истерички" - предложил отключать HT тем, кому это важно.

    Ну дык, всё ж логично. SMT теоретически позволяет удвоить производительность. Патчи ядра, закрывающие дырки, снижают производительность вдвое, причём не факт ещё, что полностью защищают. Так какой смысл тогда от SMT для людей, которым важна безопасность?

     
  • 2.250, Аноним (250), 18:19, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Он уже перешёл на AMD и Gentoo?
     

  • 1.5, Аноним (5), 10:48, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    >Арьян ван де Вен (Arjan van de Ven) из компании Intel рассказал, что Intel и AMD не рекомендуют применять STIBP по умолчанию, так как данную функциональность можно сравнить с очень тяжёлым молотком, который не используется в повседневной работе, но необходим при определённых обстоятельствах.

    Нет, это SMT/HT - дырявый костыль, который непригоден для повседневной работы, а необходим только для накрутки тестов.

     
     
  • 2.9, ryoken (ok), 10:58, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    IBM-у скажите, а то они бедные понапридумывали POWER-ов с 4-8-потоками на ядро, и знать не знают, что это костыль.
     
     
  • 3.39, Аноним (39), 11:42, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Иди читай статью "Protecting your POWER9 servers against “Spectre” and “Meltdown”"
    https://www.ibm.com/support/knowledgecenter/en/POWER9/p9hby/p9hby_speculative_

    Такая же помойка как и Intel

     
  • 3.116, КО (?), 15:04, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Есть разница между модным RISC и пинаемым всеми CISC.
    RISC по своей структуре команд плохо нагружает исполнительные устройства. И создание нескольких очередей на блок исполнительных устройств одно из решений данной проблемы. (один поток грузит по близкой ссылке адрес операнда, другой читает операнд из памяти, третий выполняет собственно команду, четвертый перепрыгивает свои операнды.) В CISC, обычно, нет избыточных операций и большая часть операций либо ждет загрузки из памяти в кеш, либо выполняет действия. Поэтому эффект не такой осязаемый.
     
  • 3.124, Ха (?), 15:34, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Они знают что такие сервера стоят в локальной сети предприятий и чтобы написать своё ПО для него написать которые бы эксплуатировало уязвимость нужно получить одобрение из айбиэм.
     
  • 3.129, Аноним (139), 16:59, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Spectre покажет им что есть что.
     
  • 2.10, Аноним (10), 11:02, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    >SMT/HT - дырявый костыль, который непригоден для повседневной работы, а необходим только для накрутки тестов

    Так непригоден, что рендерится в vray/arnold за ночь с ним и сутки без него. Ага-ага.
    Подумал бы, прежде чем писать.

     
     
  • 3.18, Онанимус (?), 11:12, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Так непригоден, что рендерится в vray/arnold за ночь с ним и сутки без него.

    Вы таки утверждаете, что рендеринг является повсеместно-повседневной работой?

     
     
  • 4.21, Аноним (10), 11:21, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    >Вы таки утверждаете, что рендеринг является повсеместно-повседневной работой?

    Таки да. Как минимум, большинство знакомых с этим сталкиваются.

     
     
  • 5.22, Аноним (39), 11:23, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Человек-анекдот(ический пример) пощади!
     
     
  • 6.55, Аноним (55), 12:03, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты не понимаешь, что прямо сейчас опеннет в твоём браузере рендерится на CPU и с HT это было бы намного быстрее?
     
     
  • 7.80, Аноним (39), 12:59, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +7 +/
    И точно! Добавил в резюме строку "Занимаюсь рендерингом более 15 лет!"
     
  • 7.166, Онаним (?), 20:18, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На практике с HT на интелях это обычно выходит медленнее.
     
  • 5.159, Аноним (159), 19:10, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Таки да. Как минимум, большинство знакомых с этим сталкиваются.

    Большинство членов африканского племени тумба-юмба едят человечину. Значит ли это, что человеческое мясо должно продаваться в магазинах Исландии?

     
  • 4.27, Fracta1L (ok), 11:27, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Нет конечно. Процессоры существуют только чтоб в Дотан гонять.
     
  • 4.74, Ыыы (??), 12:47, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >непригоден для повседневной работы
    >Вы таки утверждаете, что рендеринг является повсеместно-повседневной работой?

    А зачем вы таки вводите новое понятие в течение разговора?

    Это, конено, не повсеместно-посведневая работа, но для кого-то очень даже повседневная, пусть даже если она не является таковой в вашем кейсе.

    Говорю как человек, сидящий рядом с отделом видеопродакшена.

     
     
  • 5.76, Аноним (39), 12:50, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –5 +/
    > сидящий рядом с отделом видеопродакшена.

    И что весь отдел на линуксе? Не? А что вы его притянули в обсуждения патчей ядра? А?

     
  • 3.38, backbone (ok), 11:42, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Так непригоден, что рендерится в vray/arnold за ночь с ним и сутки без него. Ага-ага.

    Подумал бы, прежде чем писать.

    Когда тестировал обработку mp3 лет 5 назад, HT давал 30%, не более. Прирост до 2-х раз слабо верится. :)

     
     
  • 4.53, Fracta1L (ok), 12:00, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Когда идел на гентухе, ядро при включенном НТ компилялось ~ в 2 раза быстрее
     
     
  • 5.58, Аноним (39), 12:08, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >ядро при включенном НТ компилялось ~ в 2 раза быстрее

    Потом проснулся, да?

     
     
  • 6.67, Fracta1L (ok), 12:35, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > перестал пользоваться гентой
    > проснулся

    Ну, можно и так сказать XD

     
     
  • 7.165, Аноним (165), 20:16, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Но почему?)
     
  • 3.118, Аноним (118), 15:08, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А количество потоков при этом одинаковое?
     
  • 3.150, Аноним (150), 18:13, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вот как раз именно рендеринг HT/SMT не могут ускорять кратно даже теоретически.
     
     
  • 4.221, КО (?), 12:46, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Все зависит от количества потоков, которые может запускать программа. В принципе на ядро их можно пускать 2. Один поток ждет ввода-вывода, второй считает. Причем HT даже немного ускоряет это дела - не надо лишний раз полностью контекст переключать. Но беда с HT в этом смысле, что виртуальные ядра заменили реальные, а реальные стали светить в другом месте. А 4 потока на ядро - чересчур. Если программа в расчете на это, запускает столько потоков сколько ядер, то какие-то ядра не загружены, пока ждут, если нет HT.
     
  • 3.174, Аноним (174), 21:22, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > рендерится в vray/arnold за ночь с ним и сутки без него

    С защитой от Spectre v2 будет рендериться сутки с ним и двое без него. Не проще отключить HT?

     
     
  • 4.199, Аноним (198), 02:22, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не проще ли отключить дeбильную защиту?
     
     
  • 5.201, _ (??), 02:50, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда твой рендеринг будет не твой ... и даже не мой! (С) :)
     
     
  • 6.227, нах (?), 17:14, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Тогда твой рендеринг будет не твой ... и даже не мой! (С)

    а он и так уже давно...

     
  • 5.225, Аноним (225), 16:46, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Не проще ли отключить дeбильную защиту?

    1. Имеет ли смысл вкладывать человеко-часы в добавление защиты, если основным юзкейсом будет "отключить её"?
    2. Защита так реализована, что на некоторых тестах даже в отключенном виде приводит к 30% падению производительности.

    Нет, не проще.

     
  • 2.63, Аноним (139), 12:26, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >SMT/HT - дырявый костыль, который непригоден для повседневной работы, а необходим только для накрутки тестов

    Я этот костыль отключаю при сборке ядра ещё с середины 2000-х. Тогда это рекомендовалось по другой причине: HyperThreading, на самом деле, часто приводил к снижению производительности на реальных задачах. Так что, к повышеннной производительности от его наличия не привык, если таковая действительно имела место быть.
    Вот теперь задуваюсь, нафига переплачивать, покупая Ryzen 5, 7, если этой возможностью не пользоваться?

     
     
  • 3.167, Онаним (?), 20:19, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    На Ryzen'ах SMT - очень хорош, +10-20% к производительности во многих задачах. И не дыряв.
     
  • 3.195, Аноним (194), 01:49, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А вот и супер гуру-оптимизаторщики из поста #194
     
  • 2.145, Аноним (145), 17:41, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >непригоден для повседневной работы

    О как, а мужики-то и не знали. Теперь придется покупать шестнадцатиядерник вместо восьмиядерника

     

     ....большая нить свёрнута, показать (33)

  • 1.12, Анончик999999 (?), 11:03, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, когда очередь видеокарт придет?
     
     
  • 2.14, Анончик999999 (?), 11:04, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    на выявление такого рода уязвимостей.
     
     
  • 3.24, mickvav (?), 11:25, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Когда научатся видеонарты между процессами делить эффективно.
     
     
  • 4.33, Аноним (39), 11:35, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Майнинг ферма на 2х ядерном celeron и 8 видеокарт? Нет не слышал.
     
     
  • 5.43, Crazy Alex (ok), 11:44, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    на майнинг-ферме можно хоть в ring0 всё гонять
     
     
  • 6.46, Аноним (39), 11:47, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Чукча ветки не читатель?
     
     
  • 7.71, Аноним (71), 12:45, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Просто он, очевидно, понимает истинную ценность виртуальных фантиков. В отличие от.
     
  • 7.83, Crazy Alex (ok), 13:06, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    на ферме крутится небольшой жёстко определённый набор софта, который не грузит скрипт откуда попало, дальше она закрыта файрволлом примерно для всего, если хозяин не полный дeбил. Внутри там защищаться не от чего.
     
     
  • 8.87, нах (?), 13:10, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    более того, если ее поломают - то только через тот самый скрипт поскольку он хо... текст свёрнут, показать
     
  • 2.23, Аноним (39), 11:24, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А загуглить Nvidia Specter религия не позволяет? Песец давно пришел.
     
  • 2.30, Аноним (30), 11:31, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Недавно проскакивал сентябрьский доклад http://www.cs.ucr.edu/~zhiyunq/pub/ccs18_gpu_side_channel.pdf с методом определения содержимого экрана другого процесса через side channel атаку на видеопамять. Но там озвучены уже давно известные проблемы и для атаки требуется запуск вредоносной OpenGL- или CUDA-программы.
     
     
  • 3.106, J.L. (?), 14:39, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    //offtop

    > Недавно проскакивал сентябрьский доклад http://www.cs.ucr.edu/~zhiyunq/pub/ccs18_gpu_side_channel.pdf
    > с методом определения содержимого экрана другого процесса через side channel атаку
    > на видеопамять. Но там озвучены уже давно известные проблемы и для
    > атаки требуется запуск вредоносной OpenGL- или CUDA-программы.

    так вот как в Wayland'е скриншоты снимают?

     

  • 1.13, Онанимус (?), 11:04, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Резюмируя: видится оптимальным использование автоматической проверки на наличие SMT/Hyper-Threading перед включением STIBP.
     
     
  • 2.26, Аноним (39), 11:27, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >Резюмируя: видится оптимальным использование автоматической проверки на наличие SMT/Hyper-Threading перед включением STIBP.

    и автоматического отключения, трололо.

    А когда обнаружат Specter 3,4,5...99 - отключить пользователю вся ядра кроме одного.
    Для его же безопасности.

     
     
  • 3.131, Аноним (131), 17:07, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    не - тогда уже начнут отключать пользователя.
     

  • 1.16, Аноним (16), 11:07, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –11 +/
    Торвальдс был бы куда адекватнее, если бы озадачился целесообразностью становиться сообществу рачком перед вендорами и поддерживать этот зоопарк дырявого железа. Запилил бы глобальный краудфандинг на чистые от закладок машинки. Сколько времени свободного у разрабов бы появилось! Занимались бы спортом и не дохли перед мониторами от сердечных заболеваний, как мухи.
     
     
  • 2.29, Аноним (29), 11:31, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Сколько времени свободного у разрабов бы появилось!

    Потому что никто бы не профинансировал, как в своё время хотелку Шаттловорта?

     
     
  • 3.154, Ку (?), 18:41, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Хотелка Шаттловорта теперь вращается на Самсунгах.
     
  • 2.49, 123 (??), 11:50, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Торвальдс был бы куда адекватнее, если бы озадачился целесообразностью становиться сообществу рачком перед вендорами и поддерживать этот зоопарк дырявого железа

    Основных спонсоров Линукс фондейшн загуглите.

     
     
  • 3.170, Аноним (16), 20:55, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Что сказать-то хотел?
     
  • 2.62, Kroz (??), 12:25, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вы весьма наивны
     
  • 2.103, llolik (ok), 13:57, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну, допустим, он собрал. Кто бы их покупал? В каком количестве? Для каких целей? Кто бы их производил (не сам же Линус)? С какой себестоимостью за единицу? Где это всё продавать? Как доставлять покупателю? Кому осуществлять поддержку пользователей? ... Оно ему вообще надо?

    Если это и тролль-пост, то как-то уж настолько наивно, что даже толсто.

     
     
  • 3.137, Аноним (139), 17:29, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Почему Торвальдс все эти вопросы должен решать единолично? Существует разделение обязанностей. Желающие заниматься оргвопросами нашлись бы.
     
     
  • 4.169, llolik (ok), 20:27, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Желающие заниматься оргвопросами нашлись бы.

    Это не оргвопросы, это бизнес-план. И с вероятностью 99% он провальный т.к. круг тех, кому это действительно надо (зачем?) очень маленький, а рынок железа и так перенасыщен.

    Все ровно те же вопросы, кстати говоря, к примеру, стоят и перед МЦСТ с её Эльбрусами, но там хотя бы заказчики есть (причём весьма специфические), а следовательно какой-никакой рынок сбыта, и у них, ни шатко ни валко, но в общем-то что-то получается.

     
  • 2.140, Аноним (130), 17:31, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Запилил бы глобальный краудфандинг на чистые от закладок машинки...

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

     
     
  • 3.157, Аноним (157), 19:06, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Или даже не продавались. Как убогие эльбрусы, например.
     
  • 2.176, электронщег (?), 21:29, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А эти ребята чем, по вашему, занимаются?

    https://www.raptorcs.com/
    https://puri.sm/

     

  • 1.17, Ilya Indigo (ok), 11:08, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Очень адекватное предложение!
     
     
  • 2.50, Аноним (39), 11:54, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А что еще остается? Выкинуть все процессоры с 2012 в помойку?
    Все на RISC-V? Где кстати они в продаже?
    Отключить всем HT/SMT? И все ядра кроме одного для надежности?
     
     
  • 3.59, Ilya Indigo (ok), 12:15, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А что еще остается?

    Кому? Предложение направлено разработчикам ядра, а не лично Вам. Альтернатива применять патчи принудительно.
    > Выкинуть все процессоры с 2012 в помойку?

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

    Даже если Вам нужно и то и то
    Процессоры Intel i5 не имеют HT (если не ошибаюсь).
    AMD FX не имеют SMT.
    Выкидывать не обязательно, даже в некоторых процессорах и отключать нечего.
    > Отключить всем HT/SMT?

    Читайте Выше, если не осилили прочитать и понять новость.
    > И все ядра кроме одного для надежности?

    Этого делать не нужно.

     
     
  • 4.81, НяшМяш (ok), 13:00, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Процессоры Intel i5 не имеют HT (если не ошибаюсь).

    Всё верно. Ещё есть i7 9700k - 8 ядер без HT + пара фиксов мельдония в хардваре. Я как раз себе такой взял вместо i5 4670.

     
     
  • 5.88, ынтел (?), 13:11, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    правильно, покупайте наших слонов!
     
  • 5.90, Аноним (90), 13:11, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Именно такой процессор проработал год и умер (точнее он то работает), но не возможно даже винду на нём переустановить. 30К руб на ветер. Пришлось из-за этого попасть на покупку новой материнской платы, и нового процессора.

    Ктож знал, что процессор дохлый(

     
     
  • 6.93, Аноним (39), 13:17, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +8 +/
    >такой процессор проработал год
    > i7 9700k
    > Launched October 19, 2018
    > ГОД

    Еще чего расскажешь?

     
     
  • 7.158, Аноним (157), 19:08, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да он, наверное, просто у китайцев инженерный образец купил.
     
  • 6.136, Аноним (139), 17:24, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >умер (точнее он то работает), но не возможно даже винду на нём переустановить

    Что-то плохо парсится. Как это?

     
     
  • 7.141, Аноним (130), 17:34, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Intel вместо Minix в прошивках теперь устанавливает форточки, видимо.
     
  • 5.155, Ку (?), 18:47, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Для каких задач?
     
  • 4.162, VINRARUS (ok), 19:50, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Процессоры Intel i5 не имеют HT (если не ошибаюсь).

    Имеют.
    https://laptoping.com/cpus/wp-content/uploads/2016/10/Intel-Core-i5-7200U-7th-

     

  • 1.19, iPony (?), 11:13, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ну вот почти год прошёл, а процессоров залатанных невидно на горизонте...
     
     
  • 2.28, Аноним (39), 11:30, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    i9 9900k поокупай да.
    >Компания Intel представила сегодня девятое поколение процесоров Intel Core. Первые чипы в линейке предназначены для энтузиастов. ... и имеют аппаратную защиту от уязвимостей Spectre и Meltdown.
     
     
  • 3.56, Онанимус (?), 12:04, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > i9 9900k поокупай да.
    >>... и имеют аппаратную защиту от уязвимостей Spectre и Meltdown.

    В которой немедленно найдут мельдоний.

     
  • 3.66, Xasd (ok), 12:31, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > и имеют аппаратную защиту от уязвимостей Spectre и Meltdown.  

    тут без подробстей не обойтись:

    под фразой "аппаратная защита" может подразумеваться что угодно :-) ,

    вкючая "вызывайте чистку кэша перед опасной операций -- через вот эту новую аппаратную инструкцию!" и при этом "опасные места ищите сами!".

    ну или может быть другая ситуация "аппаратная защита есть, но ОТКЛючена поумолчанию и НЕ рекомендована к использованию (из-за побочных эффектов производительности). но для галочки мы её сделали"

     
     
  • 4.196, Аноним (194), 02:06, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Там всего лишь микрокод новый вшили для одной из многочисленных дыр
    И он работает не сам по себе а лишь с уже встроенными костылями в саму ОС...
    https://www.youtube.com/watch?v=5ko6vzCUykg
     
  • 3.114, Аноним (114), 14:57, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Нет там аппаратной защиты от Spectre, только Meltdown и l1tf
     
     
  • 4.214, Акакжев (?), 09:23, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > только Meltdown и l1tf

    Догнали свои же Атомы. :)

     

  • 1.37, имя (?), 11:40, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А отключить как?
     
     
  • 2.99, iPony (?), 13:43, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Для Ubuntu так https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown/Mitigati
     
     
  • 3.208, Олег (??), 07:23, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не раьотает 50% опций
     

  • 1.41, Виталий (??), 11:43, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Представляю как взбесятся продажи у первого выпустившего процессор без уязвимостей медтдаун спектре. Многие же не обновляют системы только потому что ждут камни с этими багфиксами.
     
     
  • 2.45, Аноним (39), 11:46, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Никак. Всем на...ть. Даже половина уязвимых сайтов HeartBleed не пофиксили до сих пор.
     
  • 2.186, Онаним (?), 23:33, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Без мылдауна - верю, это чисто проблема интела.

    Без спектра - фигушки, это архитектурная проблема. Причём архитектурная безотносительно конкретной реализации, подвержены что x86, что arm, что mips, если есть спекулятивное выполнение.

    Поэтому заткнуть это дело будет совершенно непросто, а от спекулятивного выполнения не отказаться - процы начнут летать низенько-низенько.

     
     
  • 3.187, Онаним (?), 23:34, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Чистить вовремя (читать - на практике - на каждый чих, "вовремя" тут очень скользкое понятие) очередь/TLB/кэш - тоже самое, что уже и видим даже со всеми инструкциями-хелперами производительность прососала уже -40%, и то ли ещё будет.
     
     
  • 4.215, Акакжев (?), 09:26, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > уже -40%, и то ли ещё будет.

    Во времена Pentium II можно было отключить L1 кэш в БИОС некоторых плат. Попробовал. Не дождался загрузки Windows 98.

     

  • 1.44, Виталий (??), 11:45, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Имею в виду сравнительно доступные, а не то что 9900...
     
  • 1.61, Аноним (61), 12:22, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    всё интересней и интересней
    в погоне за прибылью сначала наделали кучу железного лома на корню игнорируя безопасность, а затем начинают героически бороться с последствиями
    Вот только не говорите что проектировщики этого всего были не в курсе потенциальных уязвимостей их архитектуры, там сидят отнюдь не дураки которые которые не могут просчитать последствия на несколько шагов вперед.
     
     
  • 2.65, Fracta1L (ok), 12:30, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Как распознать 14-летнего подростка? У него весь мир делится на дураков и гениев со сверхчеловеческими способностями.
     
     
  • 3.142, Аноним (61), 17:35, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а еще мир делится на тех кто читает внимательно и тех кто читает и как следствие понимает по диагонали
    я говорил о том что при проектировании они осознанно пошли на нарушение безопасности своей архитектуры дабы в свое время задавить конкуренцию, сейчас это им аукается, но время уже прошло и имеем то что имеем
    где ты тут увидел дураков и гениев, это все порешал рынок, сынок
     
     
  • 4.148, Fracta1L (ok), 17:52, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > при проектировании они осознанно пошли на нарушение безопасности

    Инфа прямиком из астрала?

     
     
  • 5.152, Аноним (61), 18:21, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    а вы хотите верить в то что это всё случайность и банальная некомпетентность профессиональных инженеров ?
     
     
  • 6.160, Fracta1L (ok), 19:22, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это не то и не другое, это очередное, миллиардное по счёту проявление ограниченности человеческого внимания и мышления.
     
  • 2.68, Cradle (?), 12:37, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    те кто там сидят просчитывают только те последствия, за которые им зарплату платят. Если им за безопасность до сих пор не доплачивали, они и не заботились.
     
  • 2.72, Аноним (72), 12:45, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Разработчики не принимают решения, а менеджер ради красивого графика маму продаст, впарит любое г-но, а потом обвинит во всех грехах разработчика
     
  • 2.86, Анонон (?), 13:09, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Все так. Картина выглядела как при любой разработке. Инженер работает, получает деньги, кормит семью. На работе задачи, он их решает. На задачи выделено время, люди. Если времени или людей не хватает используется наиболее простое решение и неважно насколько оно правильное. Менеджер ставится в известность, ЕСЛИ ошибка замечена. И менеджер принимает решение о выделении дополнительных ресурсов на исправление ошибки ЕСЛИ посчитает нужным.
    Никто не будет просто так бесплатно сидеть и делать безопасный HT для Intel просто потому что это честно.
     
  • 2.143, Аноним (130), 17:37, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот только не говорите что проектировщики этого всего были не в курсе потенциальных уязвимостей их архитектуры

    Были, но маркетологи в их голове взяли вверх. А потом они выпустили i9, который, якобы, защищён от этих уязвимостей на аппаратном уровне.

     

  • 1.82, Анонн (?), 13:04, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > It's apparently better to just disable SMT entirely, which is what security-conscious people do anyway.
    > надёжнее вообще отключить SMT/Hyper-Threading, что обычно и делают люди, озабоченные безопасностью

    Прикольно, раньше он этих самых людей
    https://www.opennet.ru/opennews/art.shtml?num=48787
    > Дополнение: Тео де Раадт (Theo de Raadt) публично предупредил о наличии серьёзной уязвимости в реализации HyperThreading,
    > рекомендуется отключить эту опцию для любых компьютеров

    называл немного другими словами, на букву m. И анонимы опеннета были с ним очень, очень солидарны.

     
     
  • 2.91, нах (?), 13:14, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ну так он же специально отпуск брал, потренироваться выговаривать "озабоченные безопасТностью" вместо м** (и может быть даже - "потрясающе!" вместо "не-зди!")

     
  • 2.138, Onanon (?), 17:29, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Тео - орёл. С самого начала принял самое верное решение насчёт HT. Так смешно видеть, как пeрeпончатые вскрываются на наших глазах и демонстрируют полное непонимание вопроса и двойные стандарты. Впрочем, с таким лидером, как Торвальдс, который является абсолютным дилетантом в ИБ со своим "security problems are just bugs" это и неудивительно.
    Какой поп, такой и приход.
     
     
  • 3.177, Аноним (174), 21:34, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > является абсолютным дилетантом в ИБ со своим "security problems are just bugs"

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

     
     
  • 4.192, Onanon (?), 00:29, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> является абсолютным дилетантом в ИБ со своим "security problems are just bugs"
    > Всем, кто обсуждает безопасность, нужно в обязательном порядке читать "хакер в столовой". Просто для общего развития.

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

     
     
  • 5.231, Аноним (225), 18:50, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А речь не о Тео Тео не предлагает накладывать на ядро десяток патчей под кажду... большой текст свёрнут, показать
     

  • 1.98, Аноним (98), 13:39, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Друзья, ответьте, а нельзя ли эту самую спекулятивность вынести из функций процессоров и перенести данную задачу на компиляторы, ОС и т.д. (в общем, на сам софт)?
     
     
  • 2.102, Cradle (?), 13:56, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    можно, только процессор тогда будет MIPS называться
     
     
  • 3.104, Cradle (?), 13:57, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    хотя и у старухи бывает оказывается, хоть и не часто: https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-chan
     
     
  • 4.132, Аноним (139), 17:13, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, значит Байкал-Т1 может быть подвержен вариантам 1 и 2.
     
     
  • 5.171, Cradle (?), 21:17, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    интересно что китайский "сын дракона" тоже делает branch prediction, как минимум версия что у STMicro, вполне возможно что и они подвержены
     
  • 2.112, КГБ СССР (?), 14:56, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Можно И это одна из самых многообещающих и перспективных, но почему-то весьма т... большой текст свёрнут, показать
     
     
  • 3.121, Cradle (?), 15:27, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    вот сейчас кто-то наверняка ввернет про Эльбрус :) Хотя, если сравнивать, MIPS создавался из тех же предпосылок и там компайлер так-же отвечает за загрузку конвеера, в этом они схожи. Но похоже MIPS оказался более разумным компромисом между упрощением процессора и усложнением компайлера, потому и лучше прижился.
     
     
  • 4.125, КГБ СССР (?), 16:28, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > вот сейчас кто-то наверняка ввернет про Эльбрус :) Хотя, если сравнивать, MIPS
    > создавался из тех же предпосылок и там компайлер так-же отвечает за
    > загрузку конвеера, в этом они схожи. Но похоже MIPS оказался более
    > разумным компромисом между упрощением процессора и усложнением компайлера, потому и лучше
    > прижился.

    Да я и сам чуть не проговорился, но делать рекламу бесплатно — это не по феншую. :)

     
  • 3.134, Аноним (139), 17:16, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Только задача эта, в целом, оказалась не по зубам человечеству. Пока. :)

    Компиляторы, наделённые AI решат проблему? :)

     
     
  • 4.144, Анонн (?), 17:38, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >>Только задача эта, в целом, оказалась не по зубам человечеству. Пока. :)
    > Компиляторы, наделённые AI решат проблему? :)

    Нет, просто "компиляторы решат". К сожалению некоторых - мир не стоит на месте.
    Неверующие могут посмотреть на раст в качестве демки современных не-академ-ЯП-компиляторов и технологий или сравнить современный gcc (и его результаты) с его 15-25-30 летним предшественником.


     
  • 4.149, КГБ СССР (?), 18:11, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не думаю. Там же не интеллект на самом деле. Надеюсь, это не надо объяснять… :)
     
  • 4.188, Онаним (?), 23:38, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Не решат. Это задача полного предсказания всех возможных комбинаций всех входных условий. Ну или самых вероятных хотя бы. То есть всего юзеринпута, ага, всё, что сложнее хелловорлд - отдыхает.
     
     
  • 5.213, Аноним (98), 09:04, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Самому софту по идее должно быть более видней, чем процессору куда и через сколько ему потребуется тот или иной участок кода, а входные данные и процессор предугадает не сильно лучше. Но видимо придётся тогда допиливать весь софт включая ос и прикладные программы.
     
     
  • 6.232, Онаним (?), 00:37, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Предлагаешь софту меняться на лету под каждый набор x, y и z? Это займёт куда больше ресурсов проца, чем спекулятивное выполнение сразу двух бранчей.
     
     
  • 7.248, Аноним (98), 10:37, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я предлагаю самому софту решать то за что сейчас отвечает ЦПУ. Поскольку софту виднее. Как минимум ему виднее какие участки кода и данные стоит спекулятивно выполнять и подгружать, а какие нет.
     
  • 3.189, Онаним (?), 23:43, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Если совсем вкратце и на спичках, то в привычных нам процессорах со спекулятивностью каждый раз при вычислениях снова и снова выполняются множество, так сказать, оптимизаций весьма скверного кода

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

     
     
  • 4.205, КГБ СССР (?), 06:24, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Если совсем вкратце и на спичках, то в привычных нам процессорах со спекулятивностью каждый раз при вычислениях снова и снова выполняются множество, так сказать, оптимизаций весьма скверного кода
    > Дело не в скверном коде. Дело в том, что оптимальный порядок исполнения
    > зависит от входных данных. На этапе компиляции эту оптимизацию сделать никак,
    > от слова совсем.

    Скажем так: эту задачу не решить при тех практиках программирования, которые нынче в ходу.

     
     
  • 5.233, Онаним (?), 00:39, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Её вообще не решить. Потому что количество возможных вариантов входных данных для одного блока JPEG-энкодера - 16*16*(2^24). И никакие "практики" не помогут написать оптимизированный заранее вариант кода под каждый из них.
     
     
  • 6.240, КГБ СССР (?), 08:46, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Её вообще не решить. Потому что количество возможных вариантов входных данных для
    > одного блока JPEG-энкодера - 16*16*(2^24). И никакие "практики" не помогут написать
    > оптимизированный заранее вариант кода под каждый из них.

    Строго говоря, решение есть, но выходит за рамки одной этой архитектуры. Оно, я думаю, в гибридных архитектурах будущего. Скажем, в пределах одной вычислительной системы для быстрых вычислений, где это возможно, используется VLIW, а для «сомнительных» вычислений — какой-нибудь x86. И над всем этим отдельный сверхэкономный процессор-диспетчер, управляемый микроядром или экзоядром, который распределяет поступающие задачи по наиболее пригодных для них подчинённым процессорам для обработки.

     
     
  • 7.244, Онаним (?), 09:50, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    VLIW - вообще не взлетел, и уже точно не взлетит. Проблема всё в том же, о чём я говорил выше. Компилятор генерит +/- универсальный код, но в зависимости от конкретных ветвлений (а конкретные ветвления зависят от входных данных) он внезапно оказывается либо оптимальным, либо нет.
     
  • 7.245, Онаним (?), 09:53, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В отличие от компилятора, CPU оперирует _законченным_ набором: код + входные данные, поэтому может делать определённые оптимизации, которые компилятору недоступны. Другое дело, что очень часто разрыв между данными и выполнением настолько мал, что, чем дожидаться окончания обработки этих данных, быстрее параллельно заранее обработать обе ветки перехода например, а потом один из результатов выкинуть.
     
  • 2.119, КО (?), 15:25, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну если ты сначала будешь читать переменные из памяти, а только потом выполнять операцию с ними же, то оно так и будет.
    типа
    a=[e]
    b=[f]
    c=[g]
    d=[h]
    a+=b
    c+=h
    [e]=a
    [g]=c
    вместо
    [e]+=[f]
    [g]+=[h]
    то оно как бы и будет, но работать будет медленнее. посему и придумали механизм подгрузки данных в кеш заранее. Поначалу думали, что единственным побочным эффектом будет замусоривание кеша. Не думали люди, что есть любители покопаться в чужом мусорном ведре.
     
     
  • 3.128, КГБ СССР (?), 16:53, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Как же не думали И думали, и знали об этом Но, согласно городским легендам, ни... большой текст свёрнут, показать
     
     
  • 4.133, Аннон (?), 17:15, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Жирно сказанно. Попробуй не заплатить программистам. Будешь тусить с железкой, которая может включаться и в биппер пищать. Ваш отличный готовый софт за месяц-два уже устарел, нужно писать новое, но мы же программистам не платим. Можете что-то на скриптовом языке или на бейсике наваять, думаю получится, что-то крутого hello world с рюшечками.
     
  • 4.146, Аноним (130), 17:45, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > скриптовых языков

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

    > сотни отличных прикладных программ

    Меня ни одна не устраивает для моих задач, этого достаточно чтобы начать писать своё? По моему вполне. И плевал я на твоё мнение.

     
  • 4.246, Онаним (?), 09:59, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вот гонево про "худшую". На практике самой производительной архитектурой оказалась как раз переусложнённая x86. ARM, MIPS и прочее в общих задачах прососало по производительности настолько, что в персональном/промышленном применении их никто всерьёз не рассматривает. ARM нашёл себе нишу в смартфонах и прочей эмбедовке, где Performance-Per-Watt важнее пиковой производительности, MIPS остался управлялкой в другого рода эмбедовке, вытеснив POWER, и конкурируя с ARM. Но самое-то весёлое, что x86 удалось оптимизировать и по энергопотреблению - и в итоге та же циска свои управляющие процы стала делать на x86. То есть, и ARM/MIPS вскоре в своих нишах придётся не сладко.
     
     
  • 5.247, КГБ СССР (?), 10:15, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Всё, сдаюсь. :)

    Осталась самая малость до наступления светлого будущего — научиться правильно использовать кольца защиты.

     
  • 5.249, нах (?), 11:13, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    да плевать вашей сиське на энергопотребление ASR9900 в минимуме снабжена спарко... большой текст свёрнут, показать
     
     
  • 6.251, Онаним (?), 20:20, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В младшей 5505 геоды были )
     
  • 2.123, Crazy Alex (ok), 15:31, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Труп итаниума уже есть, зомби-Эльбрус шевелится усилиями гос-некромантов. Больше щдураков не нашлось.

    Некоторые идеи красивы только на бумаге.

     
     
  • 3.153, Аноним (153), 18:39, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >Некоторые идеи красивы только на бумаге.

    Правильно пишете! А как дошло дело до реализации, то появились всякие спектры и мельтдауны )))

     
     
  • 4.168, Онаним (?), 20:21, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На зомбях подобное появится не может просто в силу того, что те либо мертвы, либо не нужны.
     
  • 3.191, Ку (?), 23:50, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Чем тебе Эльбрус не угодил? Вполне себе решение, просто цена сейчас не адекватная.
    Видно, что ребята знают что делают. Вообще думал, что в России компетентных людей в этом вопросе не осталось, а оно вон как.

    Я бы взял, особенно в ноутбучном исполнении. Это был бы самый неуловимый Джо из всех известных.

     
  • 2.163, VINRARUS (ok), 19:59, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Друзья, ответьте, а нельзя ли эту самую спекулятивность вынести из функций процессоров и перенести данную задачу на компиляторы, ОС и т.д. (в общем, на сам софт)?

    С таким же успехом прогноз погоды можна заменить подводной лодкой.

     

     ....большая нить свёрнута, показать (33)

  • 1.127, Аноним (127), 16:50, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > > So why do that STIBP slow-down by default when the people who *really*
    > > care already disabled SMT?
    >
    > BTW for them, there is no impact at all.

    С подвохом. STIBP не включается при запуске ведра с nosmt ключом. Можно прострелить себе обе ноги убрав HT через efi и оставив STIBP.

     
  • 1.161, Аноним (161), 19:47, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Линус Торвальдс молодец. Защитник, лидер и борец.
     
     
  • 2.173, Аноним2 (?), 21:19, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это надо писать в 4-ре строки
     

  • 1.164, Онаним (?), 20:16, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Молодец. Потому что падение производительности от этого дерьмища перешло все разумные пределы. Ещё бы кто-то интелов на отзыв процов продавил, всё равно себестоимость камня - копейки.
     
     
  • 2.179, нах (?), 22:13, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    молодец был бы, если бы самый первый, kpti патч, заставил сделать условно-компилируемым, и проверять на потери производительности в отключенном режиме.
    Тогда и следующим было бы неповадно, и копипастеры из freebsd бы, может, призадумались. Но, видимо, интел очень просил такого не делать - а то ж этот тест запросто можно и другим боком повернуть.

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

    Беги, пингвиноид, за i9, тебя уже ждут с подставленным мешком для денег.

     
     
  • 3.181, Аноним (181), 22:24, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Nah нах, meltdown дергается банально. Спектры могли бы, да.
     
     
  • 4.219, нах (?), 10:33, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    меня не очень беспокоит банально-дергаемая уязвимость readonly и требующая запус... большой текст свёрнут, показать
     
     
  • 5.222, КО (?), 12:49, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Среди атак на HT, не все readonly. Теоретически можно и другой процесс заставить считать, что загруженное из атакуещего потока в кеш число хранится по тому же адресу, который собирается прочитать атакуемый процесс.
     
  • 3.184, Онаним (?), 23:27, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не, ну то, что интел читеры относительно access latency, и в итоге говнище с обработкой прав доступа к памяти таки вылезло на свет - ежу понятно. И то, что процы с meltdown (обходом контроля RPL/CPL) надо отзывать - тоже.

    Задница в том, что спектр - не результат того же читерства, и пара вариантов спектра таки и на AMD работает. И их митигация тоже не копеечная.

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

     
     
  • 4.185, Онаним (?), 23:29, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и про арм забыл, ад, спектр и там наличествует.
     
  • 4.211, Олег (??), 08:30, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >И их митигация тоже не копеечная.

    МИТИГАЦИЯ. Иисусе. Ты серьёзно?

     
     
  • 5.234, Онаним (?), 00:40, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Абсолютно.
     
  • 3.237, Онаним (?), 00:45, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну кайзер в отключенном режиме в общем каши много не просит. На практике отличить от погрешности не получилось.
     
  • 2.206, КГБ СССР (?), 06:40, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Копейки копейками, но не отзовут из-за неминуемого создания прецедента Одно дел... большой текст свёрнут, показать
     
     
  • 3.236, Онаним (?), 00:43, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот потери от смещения Amazon например в сторону AMD могут оказаться тоже не маленькими.
    Не знаю, да, что выйдет дешевле, не плавал.
     
     
  • 4.241, КГБ СССР (?), 08:56, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну вот потери от смещения Amazon например в сторону AMD могут оказаться
    > тоже не маленькими.
    > Не знаю, да, что выйдет дешевле, не плавал.

    С чего бы там быть потерям? Для большинства задач у процессоров Интела нет какого-то явного преимущества, чтобы делать людям погоду.

     
     
  • 5.243, Онаним (?), 09:45, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Потери-то не у амазона :)
     

  • 1.180, Аноним (180), 22:20, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А давайте просто все забудем про эти уязвимости. А кто вспомнит - тому глаз вон. А то и оба. И руки по локти. И в яму. И будем жить-поживать как раньше.
     
     
  • 2.183, Аноним (183), 23:10, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Нет уж.
     

  • 1.207, Аноним (207), 07:06, 21/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    И так сойдет. (c)
     
  • 1.229, голос_Геенны (ok), 17:31, 21/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Но у меня вопрос. Если я отключил HT в BIOS, то есть, вот было у меня 4 ядра и 8 каналов - стало 4 и 4, то этот патч, если он уже присутствует в firmware пакете Линукс или в винде где-то у неё там, всё равно будет замедлять мой процессор?
     
     
  • 2.235, Онаним (?), 00:42, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ты хотел сказать "потоков"?
    Если отключения при отсутствии HT не досыпали - да, будет. Для L1TF вроде досыпали. Для STIBP - х его з.
     

  • 1.238, Аноним (238), 03:13, 22/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Машина с CPU Intel под Haiku OS подвержена уязвимостям Spectre/Meltdown, или нет?
     
     
  • 2.239, Акакжев (?), 08:36, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Машина с CPU Intel под Haiku OS подвержена уязвимостям Spectre/Meltdown, или нет?

    Exploit == эксплуатация.
    Уязвимость сама по себе подобна самураю с мечём, но только без меча.

     
  • 2.242, Онаним (?), 09:45, 22/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Машина с CPU Intel подвержена двум этим типам уязвимости под любой ОС. Насчёт наличия программных затычек в конкретной ОС - к документации ОС.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру