The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 , opennews (??), 20-Окт-18, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


101. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/
Сообщение от Stax (ok), 22-Окт-18, 14:55 
> А что, вы знаете способ «проверять на предмет уязвимостей процессоры», даже ещё не известные?

Зачем вам неизвестные уязвимости?

Если боитесь неизвестных, то вообще нельзя использовать никакие процессоры со спекулятивным выполнением, а также с общим кэшем и остальным. Только жестко сбрасывать все состояние всех частей процессора при каждом переключении задач, чтобы ничего никогда не разделялось. Между прочим, о том, что архитектура современных процессоров способствует таким уязвимостям грамотные инженеры писали еще много лет назад. Почтайте документ "Side channel vulnerability factor" от semantic scholar - 2012 года, между прочим, там уже есть о причинах всех эти уязвимостей и известные примеры утечки данных через разделение структур. Пару проблем нашли еще в 2005, еще 4 в 2007 и так далее. Далее эти грамотные инженеры сделали SPARC, который очень хорошо защищен от подобных проблем.. но тут то ли маркетологи слили, то ли что еще.

> Технология SMT на x86 зарекомендовала себя... отвратительно

Где именно? На серверной нагрузке (не совсем любой, но абсолютном большинстве) - отлично. На рендеринге и другой хорошо параллелящейся нагрузке - тоже хорошо. Даже геймеры на бюджете беря "гиперпни" или core i3 с HT получают в своих играх огромный прирост от HT, если исходно ядер было мало.

HT это грамотная технология. Кстати, на тех же SPARC и Power часто потоков намного больше, чем 2. Но и на x86 легко запустить бенчмарк и убедиться.

> А сколько ещё НЕ устранили, можете сообщить?

Вам лень открыть официальные документы? Spectre всех мастей не устранили, потому что это очень сложно. Какие-то подвижки по некоторым вариациям будут в следующих поколениях.

> Meltdown — разговор отдельный.

Почему Meltdown отдельный, а L1TF / Foreshadow нет?

Ответить | Правка | Наверх | Cообщить модератору

102. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/
Сообщение от Stax (ok), 22-Окт-18, 15:51 
> На серверной нагрузке (не совсем любой, но абсолютном большинстве) - отлично. На рендеринге и другой хорошо параллелящейся нагрузке - тоже хорошо. Даже геймеры на бюджете беря "гиперпни" или core i3 с HT получают в своих играх огромный прирост от HT, если исходно ядер было мало.

Чтобы не быть голословным, сразу пруфы с моей стороны:
Рандомная нагрузка на "домашнем" четырехядерном i7 (самые разные примеры, включая компиляцию ядра) - выигрыш от HT порядка 30%: https://www.phoronix.com/scan.php?page=article&item=intel-ht...

Более серьезный 10C/20C 7900X - "почти маленький Xeon" - очень некислый выигрыш в pgbench: https://www.phoronix.com/scan.php?page=article&item=i9scalin...

По поводу рендеринга. Вот свежие тесты по последнему поколению (в котором, собственно, аппаратный фикс L1TF) - https://www.tomshardware.com/reviews/intel-core-i9-9900k-9th...,5847-8.html

На первой группе графиков сравниваем 9700K (8C/8T) и 9900K (8C/16T); у последнего на 2% больше тактовая частота, но реальная разница намного больше. А еще на второй группе 7-zip decompression впечатляет.

По поводу малоядерных pentium / core i3 и игр конкретные ссылки не дам (находится какой-то youtube шлак в основном), но такие бенчмарки были и прирост от HT при двух ядрах весьма ощутимый.
Но вообще малоядерные CPU встречаются не только на десктопах, напр. у меня простенькие серверы есть с двухядерным Atom с HT, или планшет на двухядерном Pentium с HT. Прирост от HT там весьма заметен.

Ответить | Правка | Наверх | Cообщить модератору

108. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 23-Окт-18, 10:39 
>> А что, вы знаете способ «проверять на предмет уязвимостей процессоры», даже ещё не известные?
> Зачем вам неизвестные уязвимости?

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

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

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

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

> Между прочим, о том, что архитектура современных процессоров
> способствует таким уязвимостям грамотные инженеры писали еще много лет назад. Почтайте
> документ "Side channel vulnerability factor" от semantic scholar - 2012 года,
> между прочим, там уже есть о причинах всех эти уязвимостей и
> известные примеры утечки данных через разделение структур. Пару проблем нашли еще
> в 2005, еще 4 в 2007 и так далее.

Что речь о подобных проблемах шла давно, я в курсе. Это к Intel'у вопрос, почему они не отнеслись серьёзно к этим угрозам. Сорока на хвосте доносила, что спасибо надо сказать эффективным менеджерам, гнавшим процент повышения производительности любой ценой...

> Далее эти
> грамотные инженеры сделали SPARC, который очень хорошо защищен от подобных проблем..
> но тут то ли маркетологи слили, то ли что еще.

Да, на SPARC SMT сделан куда грамотнее. Его и затронуло сильно меньше, хотя errata от Oracle тоже были.

>> Технология SMT на x86 зарекомендовала себя... отвратительно
> Где именно? На серверной нагрузке (не совсем любой, но абсолютном большинстве) -
> отлично. На рендеринге и другой хорошо параллелящейся нагрузке - тоже хорошо.
> Даже геймеры на бюджете беря "гиперпни" или core i3 с HT
> получают в своих играх огромный прирост от HT, если исходно ядер
> было мало.

Во многих задачах даёт прирост, я с этим и не спорил. Но «во многих» — это не «во всех», понимаете разницу между этими кванторами? Я всего лишь сказал, что иногда даёт и просадку (гугль с ключевыми словами «hyper threading lowers performance» в помощь). Читайте то, на что отвечаете, пожалуйста, внимательнее.

> HT это грамотная технология. Кстати, на тех же SPARC и Power часто
> потоков намного больше, чем 2. Но и на x86 легко запустить
> бенчмарк и убедиться.

Так у нас речь-то о безопасной реализации, в первую очередь. Мыщъх, добрая ему память, раскапывал подобные нынешним проблемы ещё лет десять назад. И что? — Да ничего. Поговорили и забыли. Ну, почти все забыли: я-то с тех пор HT включал только в доверенных окружениях, либо по принуждению, и до-о-олго звали меня за это параноиком. А что теперь? :)

>> А сколько ещё НЕ устранили, можете сообщить?
> Вам лень открыть официальные документы? Spectre всех мастей не устранили, потому что
> это очень сложно. Какие-то подвижки по некоторым вариациям будут в следующих
> поколениях.

Ещё раз: то, как Intel игнорировал предупреждения сторонних инженеров и то, как «решала» возникшие проблемы, не вселяет уверенности, что все проблемы в этой области найдены и исправлены. Тем более что история багов в их процессорах достаточно богатая. Если вы любите официальные документы, почитайте тогда заодно и официальные errata по их процессорам. Особенно вам понравится, думаю, про Core и Core 2, там был ад.

Насчёт «сложно» — ну, да, сложно. Только из Meltdown и Spectre именно вторая опаснее. «Мы выпустили лекарственные препараты, заражённые вирусами гепатита B и C, но больше мы препараты с гепатитом B не выпускаем, поэтому всё равно покупайте наши препараты, пусть и с гепатитом C» — звучит отлично.

Ещё раз: клиенты Intel не просто уязвимы уже (почти) год — это уже (почти) год как сведения об уязвимости доступны широкой публике. И производители ОС, браузеров и другого софта, фактически, прикрывают задницу Intel, которая продолжает производить и продавать уязвимые процессоры. Ответственность? Не, не слышали. То есть, конечно, у Intel уже сейчас есть проблемы, но они касаются долгих контрактов, так что на результатах текущего финансового года они могут и не сказаться. А вот в следующем, 2019-м... Впрочем, поживём-увидим.

>> Meltdown — разговор отдельный.
> Почему Meltdown отдельный, а L1TF / Foreshadow нет?

Потому что я не собираюсь превращать ветку в рассуждения обо всём на свете вплоть до смысла жизни и демонстрации политических разногласий, как это происходит по соседству. Начали говорить детально про SMT — давайте про него детально и говорить. К тому же, честно говоря, у меня нет сейчас столько времени поднимать свои архивы за последний (почти целый) год — а это необходимо, чтобы вести предметную дискуссию, на которую вы (ура!) настроены, по широкому кругу тем.

Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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