| |
| 2.117, Аноним (117), 09:25, 21/06/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Молодцы, open и dragon самые лучшие bsd, да и os.
Самое лучшее "программное отключение"!
| | |
| 2.132, Аноним (132), 01:13, 23/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
Смотря какими кретериями руководствоваться.С одной стороны,опёнок очень простая ( вхорошем смысле )и защищённая система,с другой мало софта и постоянно что-нибудь выкидывают,да и тормозной он очень.Стрекоза интрересна как проект,но для использования не подходит от слова "совсем".Фряха,та же имеет наибольшую поддержку оборудования,фич и софта,да и комьюнити,а нетбсд легко воткнуть в любую кофеваркуда и система очень опрятная.Другими словами,у всех свои плюсы и минусы и нет тут лучших : есть более или менее подходящие под ваши задачи.
| | |
|
| 1.2, Аноним (2), 13:49, 20/06/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
Видимо, проблема настолько глубоко заложена в архитектуре, что Intel выпустят 28-ядерный процессор (с охлаждением от холодильника), в котором потом просто отключат hyperthreading и потом скажут, мол "Наши новые процессоры не уязвимы, BUY NOW!".
Вангую уязвимость CVE 10\10 к концу 2019 года.
| | |
| |
| 2.17, Аноняша (?), 14:16, 20/06/2018 [^] [^^] [^^^] [ответить]
| –2 +/– |
HT не играет роли на производительности, как собственно и Speed Shift.
| | |
| |
| 3.37, Anonymoustus (ok), 15:43, 20/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Играет некоторую, иногда даже довольно заметную (если физических ядра два, по одному на процессор, а «ядра» четыре).
| | |
| |
| 4.40, Аноняша (?), 16:03, 20/06/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Еще есть линуксоиды с двумя физическими ядрами?
Не испытываю проблем под Intel Core i5-7600K.
| | |
| |
| 5.45, Аноним84701 (ok), 16:29, 20/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Еще есть линуксоиды с двумя физическими ядрами?
Есть мобильные версии процессоров (например в ноутах).
| | |
| |
| 6.61, Moomintroll (ok), 17:27, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
 > Есть мобильные версии процессоров (например в ноутах).
У меня мобильный 4-х ядерник без HT
| | |
|
| 5.51, Аноне (?), 16:50, 20/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
У меня G4500, от HT бы не отказался (привет веб-разрабам).
| | |
| |
| 6.112, Аноним (112), 05:03, 21/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
В этом вся суть, на сервера можно AMD EPYC поставить, там нет этих проблем с SMT.
| | |
|
|
| 4.41, Аноним (41), 16:08, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
разве что парни с двора больше уважают, так как с НТ у вас с больше квадратиков в таскманагере чем у них.
| | |
| |
| 5.57, Anonymoustus (ok), 17:00, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
> разве что парни с двора больше уважают, так как с НТ у
> вас с больше квадратиков в таскманагере чем у них.
Да, больше квадратиков. А ещё в правильно написанной малвари (например, мультимедийной) потенциально возможно ускорение вычислений. Увы, массовые программеры слабы для этого. Не оценили новаторство Интела в архитектуре четвёртого пня. Не сумели правильно применить.
| | |
| |
| 6.69, Xasd (ok), 18:06, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
 а как правильно применять?
там основной выигрыш в том что количество решистров увеличивается в двое.
но ток расскажи как писать программы чтобы в явном виде применять эти приемущства?
| | |
| |
| 7.76, Anonymoustus (ok), 19:04, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
В любом случае не так, как для P6. Возможно, что примерно так, как для современных видеокарт с тучей мелких вычислителей, только с поправкой на архитектуру и количество таковых у обычного процессора. :) Длинный и быстрый конвейер четвертопня хочет однообразных данных потоком.
| | |
|
| 6.74, Ivan_83 (ok), 18:39, 20/06/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Вообще то изначально идея была у AMD, но они посмотрели и плюнули, а интел подобрало каку и внедрило как важную фичу за которую лет 10+ брало доп бабло.
| | |
| |
| |
| 8.93, Anon1 (?), 22:20, 20/06/2018 [^] [^^] [^^^] [ответить] | +/– | Anonymoustus, пойди чтоли, перечитах про архитектуру бульзозеров и перестань н... текст свёрнут, показать | | |
| 8.97, Ivan_83 (ok), 22:38, 20/06/2018 [^] [^^] [^^^] [ответить] | +1 +/– | У них и сейчас кросслицензирование Интел сделал SIMD для SHA, и у них он почти ... текст свёрнут, показать | | |
| |
| 9.103, Аноним (103), 23:50, 20/06/2018 [^] [^^] [^^^] [ответить] | +3 +/– | x86 уже 30 лет, а конпейляторы под эту архитектуру до сих пор не научат всё сами... текст свёрнут, показать | | |
| |
| |
| 11.133, Xasd (ok), 12:07, 23/06/2018 [^] [^^] [^^^] [ответить] | +/– | искуство манагерского втирания в том чтобы они пытаются бы рассказывать про как... текст свёрнут, показать | | |
|
|
| |
| |
| 11.134, Xasd (ok), 12:12, 23/06/2018 [^] [^^] [^^^] [ответить] | +/– | ой, блин началось каких нахрен сведеней потенциальный противних уже вкурсе все... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
|
| 1.3, 1 (??), 13:49, 20/06/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +10 +/– |
"грядущие анонсы от Intel" ...
Пора открывать ИТ викиликс.
| | |
| |
| |
| 3.7, Аноним (4), 13:59, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
Я про такое дотошное отношение к безопасности. То есть про программное отключение этой уязвимости в дистрибутиве.
| | |
| |
| 4.16, Аноним (16), 14:16, 20/06/2018 [^] [^^] [^^^] [ответить]
| +3 +/– |
ув.эксперт! расскажите, пожалуйста, как отключить хайпертрединг в биос Lenovo T470...
| | |
| |
| |
| |
| 7.124, кверти (ok), 11:15, 21/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
 твою же ж мать...один на всю планету опенка на этом железе использует. Так вот из-за кого Тео так старался
| | |
|
| 6.71, Аноним (71), 18:16, 20/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> ув.эксперт! покажите, пожалуйста, openBSD на Lenovo T470...
Вопрос был про bios, а не про bsd.
| | |
| |
| 7.125, кверти (ok), 11:16, 21/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> ув.эксперт! покажите, пожалуйста, openBSD на Lenovo T470...
> Вопрос был про bios, а не про bsd.
а тема новости про опенБСД, что дальше?
| | |
|
|
|
|
|
| 2.20, Аноним (20), 14:23, 20/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Можно попробовать через cgroups сделать доступными для процессов только по одному логическому CPU из SMP пары на одном L1 кеше. Для пользовательских процессов наверняка получится (если какой-нибудь systemd не будет мешать со своей логикой), для ядерных не в курсе.
| | |
| |
| 3.46, КО (?), 16:41, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– | |
>для ядерных не в курсе.
А зачем защищаться от зловредного кода, который уже в ядре?
| | |
| |
| 4.84, PereresusNeVlezaetBuggy (ok), 20:31, 20/06/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
 >>для ядерных не в курсе.
> А зачем защищаться от зловредного кода, который уже в ядре?
Наоборот, если поток на одном виртуальном CPU — ядерный, а на втором — нехороший (взломанный, или изначально пакостный) пользовательский, вот тогда может быть ой-ой.
| | |
| |
| 5.113, КО (?), 08:26, 21/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
Так предыдущий оратор и рассказывал, как куда-то не пускать юзерспейс при помоще cgroup.
| | |
| |
| 6.116, PereresusNeVlezaetBuggy (ok), 09:12, 21/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Так предыдущий оратор и рассказывал, как куда-то не пускать юзерспейс при помоще
> cgroup.
Правильно, но надо же знать, куда не пускать. А для этого надо знать, где ядерный поток крутится. И cgroup тут не помощник, AFAIK.
| | |
|
|
|
|
| 2.34, Аноним (34), 15:29, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
CPUAffinity= в system.conf. Это поменяет affility для системдшного PID 1. Ну и, как известно, affinity наследуется дочерними процессами.
| | |
| |
| 3.48, КО (?), 16:43, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
Вопрос в том как запретить его менять. Чтоб зловред не оказался на соседнем с ядром (ну или любым другим атакуемым объектом).
| | |
|
|
| |
| 2.8, Аноним (8), 14:04, 20/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Смотря что ты понимаешь как чётные. 1, 2, 3, 4, или 0, 1, 2, 3?
| | |
| |
| 3.44, Нанобот (ok), 16:29, 20/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
 да без разницы, главное чтобы для каждой пары ядер одно из них было отключено
в более общем случае - отключить по одному ядру из hyperthreading-пары (исходя из топологии процессора)
| | |
|
| 2.35, Аноним (34), 15:33, 20/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
К вопросу о том, как линуксовое ядро нумерует ядра:
$ grep . /sys/devices/system/cpu/cpu*/topology/thread_siblings
/sys/devices/system/cpu/cpu0/topology/thread_siblings:11
/sys/devices/system/cpu/cpu1/topology/thread_siblings:22
/sys/devices/system/cpu/cpu2/topology/thread_siblings:44
/sys/devices/system/cpu/cpu3/topology/thread_siblings:88
/sys/devices/system/cpu/cpu4/topology/thread_siblings:11
/sys/devices/system/cpu/cpu5/topology/thread_siblings:22
/sys/devices/system/cpu/cpu6/topology/thread_siblings:44
/sys/devices/system/cpu/cpu7/topology/thread_siblings:88
| | |
| |
| |
| 4.95, Anon1 (?), 22:31, 20/06/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
> К счастью, больше чем на два пока никто делить не додумался. Да
> и смысла большого нет.
Кстати есть железо с 4мя потоками на ядро: Intel Xeon Phi, IBM Power7
| | |
|
|
|
| |
| 2.14, Аноним (14), 14:09, 20/06/2018 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Изначально проблема состоит в том, что в немалом количестве современных системных прошивок (BIOS/EFI), в первую очередь — в ноутбуках, отсутствует опция для отключения SMT в принципе. | | |
| |
| 3.26, ryoken (ok), 14:54, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
 >> в первую очередь — в ноутбуках, отсутствует опция для отключения SMT в принципе.
...а если и можно опцию включить ковырянием и последующим заливом файла прошивки (делал на своём дремучем Pegatron A15) - не факт, что возымеет эффект.
Вопрос в тему - а вот к POWER9 + Talos железкам про SMT - тоже актуально? Хотелось бы знать :).
| | |
| |
| 4.29, PereresusNeVlezaetBuggy (ok), 14:56, 20/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>> в первую очередь — в ноутбуках, отсутствует опция для отключения SMT в принципе.
> ...а если и можно опцию включить ковырянием и последующим заливом файла прошивки
> (делал на своём дремучем Pegatron A15) - не факт, что возымеет
> эффект.
> Вопрос в тему - а вот к POWER9 + Talos железкам про
> SMT - тоже актуально? Хотелось бы знать :).
AFAIK, проблема кросс-платформенная, но в случае с HT проявляется наиболее серьёзно.
| | |
| 4.49, КО (?), 16:45, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
Там потоков на ядро больше.
И если кеш ассоциативный, то скорее всего да.
| | |
| |
| 5.52, КО (?), 16:53, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
А может еще какой-нибудь прикол нашли, типа если сделать быстрое переключение контекста на ht ядро в коде который ложно выполнится предсказателем ветвлений, то здравствуй счастье.
| | |
| |
| 6.54, КО (?), 16:58, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
А. Так это - патч от Мельдония же работать не должен. Пока на соседнем ht ядре работает ядро таблицы же все на месте.
| | |
|
|
|
|
| 2.19, openka (?), 14:19, 20/06/2018 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Глазки совсем плохенькие? Уже и статью прочитать не можешь?
> Изначально проблема состоит в том, что в немалом количестве современных системных прошивок (BIOS/EFI), в первую очередь — в ноутбуках, отсутствует опция для отключения SMT в принципе. | | |
|
| |
| |
| |
| 4.32, openka (?), 15:13, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Так а баг-то есть? Хрен с ними - с деталями, наличие само кто-то подтвердил?
Нет. Судя по рассылке, они только подозревают о будущих уязвимостях, связанных с HT. Поэтому заранее отключили.
| | |
| |
| |
| |
| 7.137, тигарэтоя (?), 10:02, 25/06/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Понятно. Правильно их Линус назвал.
назвал и жиденько обделался примерно через месяц, именно с без-тью. да?
| | |
|
|
|
| 4.87, PereresusNeVlezaetBuggy (ok), 20:37, 20/06/2018 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Так а баг-то есть? Хрен с ними - с деталями, наличие само
> кто-то подтвердил?
У Тео и ещё кое-кого из команды, появилась подробная информация по конкретно данной уязвимости непосредственно от Ben Gras из VUSec, выявившего баг. Marc.info тупит, так что цитирую здесь:
«Thanks to Ben Gras of VUSec for sharing an early version the research paper with us. More details will be made public soon as 'tlbleed'.»
| | |
|
| 3.50, КО (?), 16:47, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ну может это старая добрая гонка, когда из ассоциативного кеша читают не по своему адресу (ну или пишут).
| | |
| |
| 4.62, Crazy Alex (ok), 17:27, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
 Если уж предполагать - то возможен, например, вариант Spectre, с общим-то кэшем... Но подход "выключить на всякий случай" (они ж ещё и дефолт в 0 поставили) умиляет.
| | |
| |
| 5.67, Аноним (-), 17:56, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Если уж предполагать - то возможен, например, вариант Spectre, с общим-то кэшем...
Увы, б3дуны прочитали ваш на опеннете и быстренько исправили коммит задним числом! :(
https://github.com/openbsd/src/commit/96c11352863a7f6240b4e5e388052f414b75f95b
> SMT (Simultanious Multi Threading) implementations typically share TLBs and L1 caches between
> threads. This can make cache timing attacks a lot easier and we strongly suspect that this will make
> several spectre-class bugs exploitable. Especially on Intel's SMT implementation which is better known as Hypter-threading. We really should not run different security domains on different processor threads of the same core.
> | | |
| |
| 6.109, Crazy Alex (ok), 00:54, 21/06/2018 [^] [^^] [^^^] [ответить]
| –2 +/– | |
Ну логично. Коммиты их я не смотрел - я все бсд исключительно в гробу видел.
Вот и чинили бы "different security domains on different processor threads of the same core", а не рубили всё подряд - вроде как не запредельной сложности задача. Благо, в одном security domain потоков может быть масса.
| | |
| |
| 7.110, Аноним (-), 01:12, 21/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Ну логично. Коммиты их я не смотрел - я все бсд исключительно в гробу видел.
Конечно же логично даже не смотреть первоисточник новости, на который ссылаются в первом же предложении. Зачем, если сразу можно строить предположения и указывать "как правильнее надо было".
| | |
| 7.114, КО (?), 08:30, 21/06/2018 [^] [^^] [^^^] [ответить]
| +/– | |
>Вот и чинили бы "different security domains on different processor threads of the same core"
Ну выделять по ядру на каждый процесс это считается как-то расточительно... :)
| | |
| 7.128, Ordu (ok), 12:02, 21/06/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Тео получил информацию об уязвимости, и скорее всего с соглашением о неразглашении -- устным или даже письменным. Ему надо закрыть дыру быстро и при этом желательно не раскрыть уязвимость. Что он и сделал успешно. Ему не всегда удаётся не раскрывать уязвимость патчем, но в данном случае удалось. Дальше будут поиски более удачного решения, разработка и внедрение найденного способа. Это может занять месяцы. Кроме того, возможно придётся дожидаться снятия эмбарго на разглашение уязвимости. А дыра закрыта уже сейчас.
Опеннет разлагающе действует на твоё мышление, оно было замещено ненавистью к бзд. Если эмоции негативно влияют на мышление, значит пора садиться в позу лотоса и заниматься дебагом своих психических процессов, с тем чтобы эмоции играли бы конструктивную роль в мышлении, а не разрушали бы его. Ты совершенно зря пытаешься достичь этих целей на опеннете, он не поможет, он лишь помешает.
| | |
|
|
| 5.100, PereresusNeVlezaetBuggy (ok), 23:31, 20/06/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Если уж предполагать - то возможен, например, вариант Spectre, с общим-то кэшем...
> Но подход "выключить на всякий случай" (они ж ещё и дефолт
> в 0 поставили) умиляет.
Ваши предложения? Сидеть и ждать?
| | |
| |
| 6.106, Crazy Alex (ok), 00:46, 21/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
Для начала - дефолтом единичку сделать. А так - да, сидеть и ждать какого-то внятного подтверждения.
| | |
| |
| 7.115, PereresusNeVlezaetBuggy (ok), 08:30, 21/06/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Для начала - дефолтом единичку сделать. А так - да, сидеть и
> ждать какого-то внятного подтверждения.
Единичка не изменит состояние дел, смысл тогда вообще что-то делать? Вполне возможно, что позднее появится какое-то более эффективное решение, и тогда можно будет значение по умолчанию поменять, так как угрозы по умолчанию уже не будет.
OpenBSD — это про надёжные значения/действия по умолчанию. Если кто-то уверен, что в его случае HT не вредит, то без проблем, пусть ставит единичку.
| | |
|
|
|
|
|
|
| 1.22, Аноним (22), 14:34, 20/06/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –8 +/– |
Лишите Тео доступа к компьютеру, а то он так и сам факт наличия CPU признает уязвимостью
| | |
| |
| 2.58, abi (?), 17:10, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
OpenBSD же форк NetBSD ? Последний был форкнут явно раньше FreeBSD 5.x
| | |
| |
| 3.85, Еще_один_аноним (?), 20:31, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
OpenBSD форкнулось от NetBSD 1.0, в 1995 году, тот в свою очередь форкался от 386BSD и к FreeBSD отношения они не имеют.
| | |
|
| 2.89, PereresusNeVlezaetBuggy (ok), 20:50, 20/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
> cause performance penalties
> under certain loads, the logical CPUs can
> be disabled by setting the
> machdep.hyperthreading_allowed tunable to zero.
> [/CODE]
> https://www.opennet.dev/openforum/vsluhforumID3/12174.html#13
>> 1.13, Аноним, 14:24, 08/09/2005
>> 2xXeon 2.8
>> machdep.hyperthreading_allowed=1
> ?
Как минимум в том, что фряшники енто дело грохнули лет семь назад, как я понимаю:
-20110608:
- The following sysctls and tunables are retired on x86 platforms:
- machdep.hlt_cpus
- machdep.hlt_logical_cpus
- The following sysctl is retired:
- machdep.hyperthreading_allowed
- The sysctls were supposed to provide a way to dynamically offline and
- online selected CPUs on x86 platforms, but the implementation has not
- been reliable especially with SCHED_ULE scheduler.
- machdep.hyperthreading_allowed tunable is still available to ignore
- hyperthreading CPUs at OS level.
- Individual CPUs can be disabled using hint.lapic.X.disabled tunable,
- where X is an APIC ID of a CPU. Be advised, though, that disabling
- CPUs in non-uniform fashion will result in non-uniform topology and
- may lead to sub-optimal system performance with SCHED_ULE, which is
- a default scheduler.
https://marc.info/?l=freebsd-commits-all&m=139939109320608&w=2
| | |
|
|
