Кипишь громкий, но по сути, никто не указал какими косяками грозит данная уязвимость. Уверен, что 70% юзеров и не заметят разницы. До нынешнего дня то все компы дожили и похуй было.
И да, я на АМД.
Это сводит в ноль плюшки KASLR. Что в свою очередь облегчает выход на уровень привелегий ядра в случае наличия уязвимостей в нем.
в Linux это еще можно будет отключить. в винде - врядли. таким образом ты скорее всего получишь те же самые -30% производительности.
но на самом деле - пока рано поднимать панику. патчи еще не выпустили, и будет ли такое падение производительности - пока под большим вопросом. возможно, intel добавит что-то в микрокод проца, что позволит уменьшить падение. да и с самим GRSecurity еще вопрос - не пытаются ли они под шумок свои патчи пропихнуть (нифига не бесплатные), которые каким-то другим способом решают эту проблему.
написано же - микрокодом не лечится. архитектурный продолб.
Ну чтож, Райзен на фоне такой хуйни смотрится еще выгодней, чем раньше. З.ы. амд на самом деле большие молодцы, что спустя 10-ти лет топтания на месте выпустили по настоящему годный проц, которые может на равных соперничать с интелом и при этом традиционно дешевле. Я за здоровую конкуренцию, она на пользу простым пользователям
Если бы вы почаще из криокамеры выходили, знали бы, что успехи у AMD чаще бывают :)
таким образом ты скорее всего получишь те же самые -30% производительности.
Но ведь
Цитата (Лиза Су @ 3.01.2018 - 13:27)
AMD не подвержены данной уязвимости — а, следовательно, и не нуждаются в ресурсоёмкой защите от неё.
а код то один на этих процах работает. и если ядро ОС начинает переключать контексты памяти (или что там эти патчи делают), то оно будет их переключать вне зависимости от проца.
другой разговор, что в линуксе это поведение можно будет отключить (опять таки - вне зависимости от процессора). будет ли такая возможность в винде - неизвестно. кстати, кто-то в курсе, ядру винды кастомные загрузочные параметры вообще можно передавать?
Ты за гентушников-то не говори...
при чем тут гентушники?
или ты не в курсе, что make oldconfig (который и genkernel может вызывать) проставляет дефолты, и скорее всего по дефолту эта опция будет включена? никто каждый раз с нуля конфиг не делает, берут последний из /etc/kernels, копируют рядом с новым именем, затем make oldconfig, ну и максимум - пробежаться глазами по конфигу, если совсем заняться нечем.
или в генте каким-то особенным способом параметры ядру передается? так нет же, /etc/default/grub, как и везде с grub2
P.S. гентушник с 2008 года, если что
А Вы каждый раз ядро заново конфигурируете? odconfig адаптирует .config или /proc/congig.gz к новой версии ядра. Дефолтом ставит только новые параметры, которых не было у обновляемого ядра. Если есть сомнения, раз в неделю не в лом набрать make menuconfig. Я с 2005го ядра без genkernel/initrd собираю.
Это сообщение отредактировал andrew1969 - 3 янв 2018 в 15:49
в Linux это еще можно будет отключить. в винде - врядли. таким образом ты скорее всего получишь те же самые -30% производительности.
но на самом деле - пока рано поднимать панику. патчи еще не выпустили, и будет ли такое падение производительности - пока под большим вопросом. возможно, intel добавит что-то в микрокод проца, что позволит уменьшить падение. да и с самим GRSecurity еще вопрос - не пытаются ли они под шумок свои патчи пропихнуть (нифига не бесплатные), которые каким-то другим способом решают эту проблему.
написано же - микрокодом не лечится. архитектурный продолб.
понятно, что полностью не лечится но, возможно, падение производительности в новых патчах частично компенсироуется обновлением микрокода. это так, предположение. intel просто обязан будет что-то с этим делать, т.к. иначе сложно сказать, как на всё это отреагирует рынок.
так я не понял, если у меня АМД, то снижение производительности меня не затронет?
Возможно, придётся с blacklist modules пошаманить и параметрами в загрузке ядра. А может быть вообще ничего делать не придётся. Но погуглить, дабы убедиться, что оно отключено - скорее всего да.
в Linux это еще можно будет отключить. в винде - врядли. таким образом ты скорее всего получишь те же самые -30% производительности.
но на самом деле - пока рано поднимать панику. патчи еще не выпустили, и будет ли такое падение производительности - пока под большим вопросом. возможно, intel добавит что-то в микрокод проца, что позволит уменьшить падение. да и с самим GRSecurity еще вопрос - не пытаются ли они под шумок свои патчи пропихнуть (нифига не бесплатные), которые каким-то другим способом решают эту проблему.
написано же - микрокодом не лечится. архитектурный продолб.
понятно, что полностью не лечится но, возможно, падение производительности в новых патчах частично компенсироуется обновлением микрокода. это так, предположение. intel просто обязан будет что-то с этим делать, т.к. иначе сложно сказать, как на всё это отреагирует рынок.
Не думаю, что мой домашний комп относится к целевой аудитории хакеров.
хакеры по ЦА не работают, если ты, конечно, не суперважная пися, они ковровым бомбометанием распространяют заразу. Вот подхватишь шифровальщик, который пролез через эту дыру, толку от твоих заявлений?
А Вы каждый раз ядро заново конфигурируете? odconfig адаптирует .config или /proc/congig.gz к новой версии ядра. Дефолтом ставит только новые параметры, которых не было у обновляемого ядра.
ты вообще прочитал мое сообщение? или я не то же самое написал?
Цитата
Если есть сомнения, раз в неделю не в лом набрать make menuconfig.
ммм, нафига раз в неделю то? ядра реже выходят.
да и зачем make menuconfig для просмотра? если есть /proc/config.gz либо /etc/kernels, либо /usr/src/linux/.config?
Цитата
Я с 2005го ядра без genkernel/initrd собираю.
я так и не понял, какой смысл отказываться от initrd/initramfs особенно с учетом того, что я активно пользуюсь LVM
а genkernel обычно избегают те, кто думает, что там какая-то магия. хотя на самом деле - он просто автоматизирует ручную работу и ничего сам не портит.
так я не понял, если у меня АМД, то снижение производительности меня не затронет?
Возможно, придётся с blacklist modules пошаманить и параметрами в загрузке ядра. А может быть вообще ничего делать не придётся. Но погуглить, дабы убедиться, что оно отключено - скорее всего да.
насколько я понял, никаких модулей для этого не планируется, поэтому - никакого blacklist не понадобится. только параметры при загрузке.
и не забывай, что ты не на линуксовом форуме, тут 99% виндузятников. и как там будет - пока неизвестно.
А Вы каждый раз ядро заново конфигурируете? odconfig адаптирует .config или /proc/congig.gz к новой версии ядра. Дефолтом ставит только новые параметры, которых не было у обновляемого ядра.
ты вообще прочитал мое сообщение? или я не то же самое написал?
Цитата
Если есть сомнения, раз в неделю не в лом набрать make menuconfig.
ммм, нафига раз в неделю то? ядра реже выходят.
да и зачем make menuconfig для просмотра? если есть /proc/config.gz либо /etc/kernels, либо /usr/src/linux/.config?
Цитата
Я с 2005го ядра без genkernel/initrd собираю.
я так и не понял, какой смысл отказываться от initrd/initramfs особенно с учетом того, что я активно пользуюсь LVM
а genkernel обычно избегают те, кто думает, что там какая-то магия. хотя на самом деле - он просто автоматизирует ручную работу и ничего сам не портит.
Используйте LVM, кто же против... Я btrfs предпочитаю. Вполне рабочая штука, но функционал RAID/LVM/SUBVOLUMES искаропки. Пока не доказано обратного (в плане работоспособности), она считается рабочей. LVM на десктопе? неее... btrfs уже готова к продакшену.
Скорее всего там такая уязвимость, которую эксплуатировать за***ся с большой буквы З. А учитывая, что системных программеров сейчас маловато, а из них пряморуких ещё меньше....То ни одно школоло и т.д. даже с помощью DDK эксплойт не выдрочит, не то что на чистом асме.
Используйте LVM, кто же против... Я btrfs предпочитаю. Вполне рабочая штука, но функционал RAID/LVM/SUBVOLUMES искаропки. Пока не доказано обратного (в плане работоспособности), она считается рабочей. LVM на десктопе? неее... btrfs уже готова к продакшену.
btrfs более-менее стабильной стала, когда я уже lvm вовсю использовал. переходить на нее не вижу никакого смысла - ни одной киллер-фичи для себя не увидел. к тому же я использую разные фс на разных томах для разных задач.
Все эти "патчи" фигня. Для защиты Ядра ОС требуется аппаратная защита: - вирус Чернобыль поражал только материнские платы с перепрограмируемой памятью... если на плате выла вынута перемычка разрешения перезаписи ЭППЗУ, то вирус не мог её попортить. - на программируемых промышленных контроллерах фирмы Сименс до 2002-го года использовался механический ключ защиты от изменения программы... ключ убрали и тут же Израиль выпустил Stuxnet. - на компах аппаратную защиту от записи можно организовать схемными методами - после загрузки ядра сбросить триггер разрешения изменения области памяти Ядра и ни одна зараза не сможет его изменить.
Все эти "патчи" фигня. Для защиты Ядра ОС требуется аппаратная защита: - вирус Чернобыль поражал только материнские платы с перепрограмируемой памятью... если на плате выла вынута перемычка разрешения перезаписи ЭППЗУ, то вирус не мог её попортить. - на программируемых промышленных контроллерах фирмы Сименс до 2002-го года использовался механический ключ защиты от изменения программы... ключ убрали и тут же Израиль выпустил Stuxnet. - на компах аппаратную защиту от записи можно организовать схемными методами - после загрузки ядра сбросить триггер разрешения изменения области памяти Ядра и ни одна зараза не сможет его изменить.
ты предлагаешь ядру ОС после загрузки перестать изменять память?
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста, или зарегистрируйтесь, если не зарегистрированы.
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
yaplakal.com
QvaziMurder3 янв 2018 в 15:35