Бляать, это пиздец Как я понял на линухе придется самому собирать ядро без kpti (kernel page table isolation), если не хочешь падения производительности (по тестам это около 15-18%)
в бутаргах загрузчика включается/выключается (pti=on/off), ядро самому не надо собирать
Походу следующий сервер в стойку буду брать на amd epyc'ах
Это сообщение отредактировал 4ipolino - 3 янв 2018 в 14:14
Давно уже нормальные специалисты поняли что Рынок- в целом и интел- в частности- не пустят на самотек ситуацию с не желающими обновлять железо- каждые полгода.
Из-за сильного влияния на производительность разработчики патча предусмотрели опцию для отключения KPTI, которая активируется через передачу параметра "nopti" при загрузке ядра.
То есть для CPU AMD ядро Linux не нужно пересобирать, хватит указать опцию при загрузке, чтобы отключить kpti и избавиться от тормозов.
Это сообщение отредактировал rmammoth - 3 янв 2018 в 14:55
таким образом ты скорее всего получишь те же самые -30% производительности.
Но ведь
Цитата (Лиза Су @ 3.01.2018 - 13:27)
AMD не подвержены данной уязвимости — а, следовательно, и не нуждаются в ресурсоёмкой защите от неё.
а код то один на этих процах работает. и если ядро ОС начинает переключать контексты памяти (или что там эти патчи делают), то оно будет их переключать вне зависимости от проца.
другой разговор, что в линуксе это поведение можно будет отключить (опять таки - вне зависимости от процессора). будет ли такая возможность в винде - неизвестно. кстати, кто-то в курсе, ядру винды кастомные загрузочные параметры вообще можно передавать?
Не думаю, что мой домашний комп относится к целевой аудитории хакеров.
Вот как раз твой домашний и относится, потому как пролезть на него - проще пареной репы. Будешь потом какие-нибудь майнеры или прочих ботов на себе таскать
Не думаю, что мой домашний комп относится к целевой аудитории хакеров.
Вот как раз твой домашний и относится, потому как пролезть на него - проще пареной репы. Будешь потом какие-нибудь майнеры или прочих ботов на себе таскать
не факт, что это вообще десктопы зацепит там судя по всему одна виртуалка может получить доступ к памяти другой, но не к памяти хост системы. так что вполне вероятно - просто вырастут цены на VPS и подобные "облака", а остальных даже и не зацепит
кстати, кто-то в курсе, ядру винды кастомные загрузочные параметры вообще можно передавать?
можно через bcdedit.exe
мдя, как обычно - через одно место
правда, насколько я понял - можно и через реестр опцию пропихнуть. только там доступ по умолчанию ro, но винда позволяет сделать его rw. остается вопрос - через .reg файл - получится это провернуть или нет....
основная проблема в том, что из-за относительной сложности этой операции - появятся разные утилиты сомнительного качества, которые якобы будут отключать этот патч...
Проблеме, скорее всего более 10лет. Был скандал с выпуском UT2004, когда пользователи обратили внимание, что производительность UT2004 на Intel раза в два ниже, чем на AMD. Intel погрозила разработчикам пальчиком, и проблема была решена тупо снижением производительности на AMD.
таким образом ты скорее всего получишь те же самые -30% производительности.
Но ведь
Цитата (Лиза Су @ 3.01.2018 - 13:27)
AMD не подвержены данной уязвимости — а, следовательно, и не нуждаются в ресурсоёмкой защите от неё.
а код то один на этих процах работает. и если ядро ОС начинает переключать контексты памяти (или что там эти патчи делают), то оно будет их переключать вне зависимости от проца.
другой разговор, что в линуксе это поведение можно будет отключить (опять таки - вне зависимости от процессора). будет ли такая возможность в винде - неизвестно. кстати, кто-то в курсе, ядру винды кастомные загрузочные параметры вообще можно передавать?
Кипишь громкий, но по сути, никто не указал какими косяками грозит данная уязвимость. Уверен, что 70% юзеров и не заметят разницы. До нынешнего дня то все компы дожили и похуй было.
У кого вот только. Вы таки уверены, что intel уже через неделю представит новую линейку без дыры? Сказано же - фундаментальная! Пока программно решают. Кстати, мало кто помнит, но году в 2011 разрабы OpenBSD тоже низкоурвневую ошибку в интелах обнаружили. Предпочитая AMD уже тогда, особо не следил.
Закрытие уязвимости требует обновления ОС, патчи для Linux уже вышли
но некоторые подробности всё-таки выплыли наружу благодаря Python Sweetness и The Register.
Некоторые подробности благодаря Python Sweetness и The Register? Издевательская новость, все ветки с патчами и обсуждениями доступны для каждого.
Чего из этого секрет и тайну делать ? Для обывателя ? Для тех кто в теме (безопасники) всегда есть отдельная конфа или канал в телеграм где доставляются планируемые патчи и часть сырцов для быстрого решения.
И так про между прочим, данная заплатка снижает производительность для СУБД которая оттопырена в интернет, для остальных это не критично. Кто в теме тот поймет.
Я вот только что сходил в гараж и обновил масло в ГУРе у своего немца , считаю что на пользу пошло . А обновлялки моя "лицензионная система " плохо переносит и они лет 5 как отключены . И да , у меня AMD .
Кипишь громкий, но по сути, никто не указал какими косяками грозит данная уязвимость. Уверен, что 70% юзеров и не заметят разницы. До нынешнего дня то все компы дожили и похуй было.
И да, я на АМД.
Изоляция приложений (защита памяти друг от друга), виртуализация. Интересно, а как в таких условиях, когда на проц положиться нельзя (как выяснилось), будет работать эвристика в том же Касперском? Ведь она основана на изоляции процессов. Которая, как оказалось, в интелах отсутствует. Всё держалось на «честном слове». Всего-то копнули AMT... Аппетит приходит во время еды. :) Отсутствие информации о дыре не означает её отсутствие.
Это сообщение отредактировал andrew1969 - 3 янв 2018 в 15:26
Проблеме, скорее всего более 10лет. Был скандал с выпуском UT2004, когда пользователи обратили внимание, что производительность UT2004 на Intel раза в два ниже, чем на AMD. Intel погрозила разработчикам пальчиком, и проблема была решена тупо снижением производительности на AMD.
эта байка никак не может иметь отношения к данной уязвимости. тупо потому что проблема не в userspace
Это сообщение отредактировал blow05 - 3 янв 2018 в 15:34
таким образом ты скорее всего получишь те же самые -30% производительности.
Но ведь
Цитата (Лиза Су @ 3.01.2018 - 13:27)
AMD не подвержены данной уязвимости — а, следовательно, и не нуждаются в ресурсоёмкой защите от неё.
а код то один на этих процах работает. и если ядро ОС начинает переключать контексты памяти (или что там эти патчи делают), то оно будет их переключать вне зависимости от проца.
другой разговор, что в линуксе это поведение можно будет отключить (опять таки - вне зависимости от процессора). будет ли такая возможность в винде - неизвестно. кстати, кто-то в курсе, ядру винды кастомные загрузочные параметры вообще можно передавать?
Ты за гентушников-то не говори...
при чем тут гентушники?
или ты не в курсе, что make oldconfig (который и genkernel может вызывать) проставляет дефолты, и скорее всего по дефолту эта опция будет включена? никто каждый раз с нуля конфиг не делает, берут последний из /etc/kernels, копируют рядом с новым именем, затем make oldconfig, ну и максимум - пробежаться глазами по конфигу, если совсем заняться нечем.
или в генте каким-то особенным способом параметры ядру передается? так нет же, /etc/default/grub, как и везде с grub2
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста, или зарегистрируйтесь, если не зарегистрированы.
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
yaplakal.com