forum.opennet.ru

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

Оглавление

Для FreeBSD и QEMU/KVM предложены механизмы блокировки атак ..., opennews (ok), 20-Фев-18, (0) [смотреть все]

Это даже круче чем новость о выпуске альфа-версии инсталлятора для Дебиан , A.Stahl (ok), 10:34 , 20-Фев-18, (1) +11 //

Во Во Люди делом занимаются, а эти из соседней темы, 200000 на бабские кружев, Аноним (-), 10:46 , 20-Фев-18, (2) –4 //

Copy Paste Refactoring Linux code for BSD, Аноним (-), 13:30 , 20-Фев-18, (12) –3
Чо ты на бабские кружева возбудился Бабам они нравятся, а ты завидуешь , Аноним (-), 09:41 , 21-Фев-18, (28) +1

Новость об альфа-версии фикшенного процассера интель бужет ещё ипичнее Рынки по, Andrey Mitrofanov (?), 11:02 , 20-Фев-18, (4)
Еще круче цитировать что-то несуществующее хотя аксакалам не привыкать Предл, Аноним (-), 15:06 , 20-Фев-18, (14)

ну как бы заголовок новости некорректный Предложили еще месяц назад Ссылка указа, я (?), 11:00 , 20-Фев-18, (3) +4 //

который, к сожалению, будет очень непросто теперь откатить Ну просто феерические, пох (?), 12:42 , 20-Фев-18, (11) –1

отлично нифига не ясно как можно засунуть KPTI внутрь Qemu, учитывая что Qemu р, X4asd (ok), 11:26 , 20-Фев-18, (5) //

в случае QUEMU - он же эмулирует поведение процессора если он эмулирует поведен, Аноним (-), 11:39 , 20-Фев-18, (6) –3
Там По ссылкам Не QEMU Ядра Патчах ядер I Meltdown mitigation via KPTI d, Andrey Mitrofanov (?), 12:13 , 20-Фев-18, (9) +1 //

то есть в Qemu поправили Meltdown через правки -- хостового ядра и гостевых ядер, X4asd (ok), 12:18 , 20-Фев-18, (10) –1

kvm , Аноним (-), 13:45 , 20-Фев-18, (13) //

а чо kvm kvm пусть сами у себя правят afaik, у них и так таблица страниц отдел, Аноним (-), 17:39 , 21-Фев-18, (31)

А как на счёт MeltdownPrime и SpectrePrime , поледанныхотсутств (?), 11:41 , 20-Фев-18, (7) –2 //

Праймы - это производные от Meltdown и Spctre Т е без них уже не живут , Neptus (?), 11:45 , 20-Фев-18, (8) +1
Новость про них почитай , anonymous (??), 16:25 , 20-Фев-18, (20)

amd64 amd64 machdep c CODE pti pti_get_default TUNABLE_INT_FETCH v, Аноним (-), 15:21 , 20-Фев-18, (15) //

только сломана, поэтому и nofetchименно так, смузи простите, гранты freebsd fo, пох (?), 15:46 , 20-Фев-18, (17) //

Ближе бздеконец, Аноним (-), 16:05 , 20-Фев-18, (18) –4
Однако, следует упомянуть, что сообщили о дыре им уже ближе к концу декабря А п, тот самый Аноним (?), 16:42 , 20-Фев-18, (21) +4 //

а какая разница - копипастили-то из понятно чего, а оно тоже только в это же вре, пох (?), 18:00 , 20-Фев-18, (22)

Вы уже своим смузи всё кругом затопили, перестаньте течь У вас то фряха плохая, , Джон Ленин (?), 21:14 , 23-Фев-18, (32)

Да, но пока нет Жедитоб, залогинься , Led (ok), 02:58 , 21-Фев-18, (23) –1

Пестят, Spectre v1 НИГДЕ ЕЩЁ НЕ ЗАКРЫТ IBRS IBPB - пурген в глаза акционер, pavlinux (ok), 04:15 , 21-Фев-18, (24) +1 //

У кого-надо - закрыт может быть Была-же новость про выпуск бетта-прошивки д, Аноним (-), 07:19 , 21-Фев-18, (26) –1 //

Новость, новость обе, IBRS и IBPB, можно заставить ОСи отрубить на время , pavlinux (ok), 17:26 , 21-Фев-18, (30)

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

15. "Для FreeBSD и QEMU/KVM предложены механизмы блокировки атак ..." +/–

Сообщение от Аноним (-), 20-Фев-18, 15:21

> но PTI пока не отключаем
amd64/amd64/machdep.c

pti = pti_get_default();
        TUNABLE_INT_FETCH("vm.pmap.pti", &pti);
        for (x = 0; x < NIDT; x++)
                setidt(x, pti ? &IDTVEC(rsvd_pti) : &IDTVEC(rsvd), SDT_SYSIGT,
                    SEL_KPL, 0);
        setidt(IDT_DE, pti ? &IDTVEC(div_pti) : &IDTVEC(div), SDT_SYSIGT,
            SEL_KPL, 0);
        setidt(IDT_DB, pti ? &IDTVEC(dbg_pti) : &IDTVEC(dbg), SDT_SYSIGT,

amd64/amd64/pmap.c:SYSCTL_INT(_vm_pmap, OID_AUTO, pti, CTLFLAG_RDTUN | CTLFLAG_NOFETCH

т.е. принципиально штатная возможность есть, нужно только убрать nofetch. А вот зачем было встраивать проверки в каждую дырку, вместо двух отдельных блоков и ifelse над ними - непонятно. Такое чувство, что плюнули на все, лишь бы как можно быстрее выкатить патч.

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

17. "Для FreeBSD и QEMU/KVM предложены механизмы блокировки атак ..." +/–

Сообщение от пох (?), 20-Фев-18, 15:46

> т.е. принципиально штатная возможность есть
только сломана, поэтому и nofetch
> Такое чувство, что плюнули на все, лишь бы как можно быстрее выкатить патч.
именно так, смузи...простите, гранты freebsd foundation не могут долго ждать, а по ним нужно отчитываться.
Подобная вредная дрянь, затрагивающая кучу тонких мест в системе, должна была быть выпущена в виде feature, специально включаемой в конфиге, а не kernel tunable, с кучей проверок на ходу.

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

18. "Для FreeBSD и QEMU/KVM предложены механизмы блокировки атак ..." –4 +/–

Сообщение от Аноним (-), 20-Фев-18, 16:05

Ближе бздеконец

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

21. "Для FreeBSD и QEMU/KVM предложены механизмы блокировки атак ..." +4 +/–

Сообщение от тот самый Аноним (?), 20-Фев-18, 16:42

>> Такое чувство, что плюнули на все, лишь бы как можно быстрее выкатить патч.
> именно так, смузи...простите, гранты freebsd foundation не могут долго ждать, а по
> ним нужно отчитываться.
Однако, следует упомянуть, что сообщили о дыре им уже ближе к концу декабря.
А перепончатые, гордо задрав гузку и мигом забыв, что дыру они нашли совсем не сами и полугодовой форе в исправлении обязанны одному из основных, платиновых танцовальщиков - наперегонки уже ехидничали о тормозах "бздунов".
Так что будем надеяться на лучшее.

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

22. "Для FreeBSD и QEMU/KVM предложены механизмы блокировки атак ..." +/–

Сообщение от пох (?), 20-Фев-18, 18:00

> Однако, следует упомянуть, что сообщили о дыре им уже ближе к концу декабря.
а какая разница - копипастили-то из понятно чего, а оно тоже только в это же время стало доступным.
> Так что будем надеяться на лучшее.
на svn up -r 329450 мы будем надеяться.
И на то, что cherry-picking вручную не окажется слишком уж сложным занятием - большинство последних патчей в STABLE - полнейший мусор (то нечто для малинок, на которых один хрен до 12 работать ничего не будет, linuxKPI, какие-то sponsored by Mellanox, актуальные только их владельцам, которым все равно надо отслеживать первоисточник и т д)
А к 12й версии, из которой это выпилить слишком геморройно (надо откатить не один и не два комита в правильном порядке, и не задеть ничего рядом), либо шах, либо ишак, либо сам Ходжа...
да, llvm они, к счастью, пока не изуродовали аналогичными gcc патчами.
надежды на то, что кто-нибудь поборет брезгливость, и переделает весь этот мусор в #ifdef FEATURE - и что такой патч примут - ноль, к сожалению.

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

32. "Для FreeBSD и QEMU/KVM предложены механизмы блокировки атак ..." +/–

Сообщение от Джон Ленин (?), 23-Фев-18, 21:14

Вы уже своим смузи всё кругом затопили, перестаньте течь.
У вас то фряха плохая, что в ней системды нет и вяленда с удевом; то фряха хорошая потому-что из неё яблоки делают (и системда с вялендом там как-бы есть); то у вас линукс плох потому-что там системда с вялендом, то наоборот хороший потому, что там вяленд с системдой содран с яблок.
Заползите в какие-то кусты, и умрите от передоза, пожалуйста.
Спасибо за внимание.

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

23. "Для FreeBSD и QEMU/KVM предложены механизмы блокировки атак ..." –1 +/–

Сообщение от Led (ok), 21-Фев-18, 02:58

> т.е. принципиально штатная возможность есть, нужно только убрать nofetch
Да, но пока нет.
Жедитоб, залогинься.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

15. "Для FreeBSD и QEMU/KVM предложены механизмы блокировки атак ..."	+/–
Сообщение от Аноним (-), 20-Фев-18, 15:21
> но PTI пока не отключаем amd64/amd64/machdep.c pti = pti_get_default(); TUNABLE_INT_FETCH("vm.pmap.pti", &pti); for (x = 0; x < NIDT; x++) setidt(x, pti ? &IDTVEC(rsvd_pti) : &IDTVEC(rsvd), SDT_SYSIGT, SEL_KPL, 0); setidt(IDT_DE, pti ? &IDTVEC(div_pti) : &IDTVEC(div), SDT_SYSIGT, SEL_KPL, 0); setidt(IDT_DB, pti ? &IDTVEC(dbg_pti) : &IDTVEC(dbg), SDT_SYSIGT, amd64/amd64/pmap.c:SYSCTL_INT(_vm_pmap, OID_AUTO, pti, CTLFLAG_RDTUN \| CTLFLAG_NOFETCH т.е. принципиально штатная возможность есть, нужно только убрать nofetch. А вот зачем было встраивать проверки в каждую дырку, вместо двух отдельных блоков и ifelse над ними - непонятно. Такое чувство, что плюнули на все, лишь бы как можно быстрее выкатить патч.
Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Для FreeBSD и QEMU/KVM предложены механизмы блокировки атак ..."	+/–
	Сообщение от пох (?), 20-Фев-18, 15:46
	> т.е. принципиально штатная возможность есть только сломана, поэтому и nofetch > Такое чувство, что плюнули на все, лишь бы как можно быстрее выкатить патч. именно так, смузи...простите, гранты freebsd foundation не могут долго ждать, а по ним нужно отчитываться. Подобная вредная дрянь, затрагивающая кучу тонких мест в системе, должна была быть выпущена в виде feature, специально включаемой в конфиге, а не kernel tunable, с кучей проверок на ходу.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Для FreeBSD и QEMU/KVM предложены механизмы блокировки атак ..."	–4 +/–
	Сообщение от Аноним (-), 20-Фев-18, 16:05
	Ближе бздеконец
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Для FreeBSD и QEMU/KVM предложены механизмы блокировки атак ..."	+4 +/–
	Сообщение от тот самый Аноним (?), 20-Фев-18, 16:42
	>> Такое чувство, что плюнули на все, лишь бы как можно быстрее выкатить патч. > именно так, смузи...простите, гранты freebsd foundation не могут долго ждать, а по > ним нужно отчитываться. Однако, следует упомянуть, что сообщили о дыре им уже ближе к концу декабря. А перепончатые, гордо задрав гузку и мигом забыв, что дыру они нашли совсем не сами и полугодовой форе в исправлении обязанны одному из основных, платиновых танцовальщиков - наперегонки уже ехидничали о тормозах "бздунов". Так что будем надеяться на лучшее.
	Ответить \| Правка \| К родителю #17 \| Наверх \| Cообщить модератору


	22. "Для FreeBSD и QEMU/KVM предложены механизмы блокировки атак ..."	+/–
	Сообщение от пох (?), 20-Фев-18, 18:00
	> Однако, следует упомянуть, что сообщили о дыре им уже ближе к концу декабря. а какая разница - копипастили-то из понятно чего, а оно тоже только в это же время стало доступным. > Так что будем надеяться на лучшее. на svn up -r 329450 мы будем надеяться. И на то, что cherry-picking вручную не окажется слишком уж сложным занятием - большинство последних патчей в STABLE - полнейший мусор (то нечто для малинок, на которых один хрен до 12 работать ничего не будет, linuxKPI, какие-то sponsored by Mellanox, актуальные только их владельцам, которым все равно надо отслеживать первоисточник и т д) А к 12й версии, из которой это выпилить слишком геморройно (надо откатить не один и не два комита в правильном порядке, и не задеть ничего рядом), либо шах, либо ишак, либо сам Ходжа... да, llvm они, к счастью, пока не изуродовали аналогичными gcc патчами. надежды на то, что кто-нибудь поборет брезгливость, и переделает весь этот мусор в #ifdef FEATURE - и что такой патч примут - ноль, к сожалению.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	32. "Для FreeBSD и QEMU/KVM предложены механизмы блокировки атак ..."	+/–
	Сообщение от Джон Ленин (?), 23-Фев-18, 21:14
	Вы уже своим смузи всё кругом затопили, перестаньте течь. У вас то фряха плохая, что в ней системды нет и вяленда с удевом; то фряха хорошая потому-что из неё яблоки делают (и системда с вялендом там как-бы есть); то у вас линукс плох потому-что там системда с вялендом, то наоборот хороший потому, что там вяленд с системдой содран с яблок. Заползите в какие-то кусты, и умрите от передоза, пожалуйста. Спасибо за внимание.
	Ответить \| Правка \| К родителю #17 \| Наверх \| Cообщить модератору


	23. "Для FreeBSD и QEMU/KVM предложены механизмы блокировки атак ..."	–1 +/–
	Сообщение от Led (ok), 21-Фев-18, 02:58
	> т.е. принципиально штатная возможность есть, нужно только убрать nofetch Да, но пока нет. Жедитоб, залогинься.
	Ответить \| Правка \| К родителю #15 \| Наверх \| Cообщить модератору