| |
| 2.7, J.L. (?), 13:05, 20/02/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Это что, антивирус?!
не антивирус, а система защиты затрудняющая эксплуатацию дырок
| | |
|
| |
| |
| 3.12, Michael Shigorin (ok), 16:34, 20/02/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
 > Иногда наблюдается даже повышение производительности
Ой, а за счёт чего так? (не нашёл в PERFORMANCE)
| | |
| |
| 4.15, solardiz (ok), 17:47, 20/02/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
 Повторюсь, но: за счет того, что урон сравним со "случайными" колебаниями, происходящими по независящим от LKRG по сути причинам. Если просто сравнивать производительность системы между ее разными перезагрузками, при разных загруженных модулях, запущенных спящих программах, то на многих аппаратных платформах результаты будут колебаться в пределах нескольких процентов (а на некоторых и хуже, иногда гораздо хуже). На некоторых получается даже как-бы стабильный эффект (пока не поменяешь что-то еще - например, версию ядра), что загрузка модуля LKRG дает плюс чуть-чуть. Но это не значит, что LKRG такой прям ускоритель. Это просто так карты^Wадреса легли. Почему изменения адресов могут такое давать? Думаю, в основном из-за низкой ассоциативности различных кешей, включая TLB. В PERFORMANCE результаты с системы, где этого эффекта почти не было. Такой эффект был, например, на лаптопе Адама, но мы те результаты не опубликовали. Сейчас посмотрел на его свежие результаты по pCFI в VM на лаптопе - там в одном тесте ускорение на 9%, а в худшем замедление всего лишь на 1.6%. Но мы же не станем говорить, что LKRG в среднем ускоряет компьютер. Мы понимаем, что это сочетание разных эффектов.
| | |
| |
| 5.22, Michael Shigorin (ok), 18:39, 20/02/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Это просто так карты^Wадреса легли.
А, то есть ещё один фактор и разлёт измеряемого вследствие остальных, превышающий влияние этого.
> Мы понимаем, что это сочетание разных эффектов.
Понял, спасибо.
| | |
| |
| 6.24, Апасный Тип (?), 21:03, 20/02/2019 [^] [^^] [^^^] [ответить]
| –7 +/– |
Ой какой сообразительный. Всегда приятно знать что мои посты удаляет более умный человек чем я.
| | |
|
| 5.25, Ordu (ok), 22:38, 20/02/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Я не люблю давать советов, когда не просят, но... давайте я это изложу как пожелание: можно не только среднее указывать в результатах, но ещё и дисперсию. Такая штука позволит видеть размеры ошибок и насколько вообще эти средние о чём-либо говорят (может быть случайный шум больше измеряемой разницы?). Кроме того, различия дисперсии задержек в экспериментальном сетапе и в контрольном -- это тоже очень полезная информация, если мы говорим о производительности.
| | |
| |
| 6.26, solardiz (ok), 00:12, 21/02/2019 [^] [^^] [^^^] [ответить]
| +/– |
Спасибо. В файле PERFORMANCE сейчас даны не только средние, но и отдельные результаты 10-ти тестов для каждого случая. Думаю, это в целом показывает картину. Важно еще то, что измеряем мы на конкретном тесте, тогда как реальное использование систем будет сильно отличаться, как впрочем и сами системы. Так что эти тесты - лишь чтобы показать общую картину и чтобы сравнивать разные версии и настройки LKRG друг с другом.
| | |
| |
| 7.29, Ordu (ok), 01:24, 21/02/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> На надо дисперсию, пусть всю гистограмму дают.
Гистограмма -- это уже график. Это дополнительные геморрои. Дисперсию же посчитать не сложнее чем среднее, и добавить её в табличку данных тоже несложно.
Если же рисовать картинки, то мне больше нравятся доверительные интервалы. Восприятие гистограммы более субъективно, нежели восприятие доверительных интервалов.
| | |
| |
| |
| 9.33, PnDx (ok), 14:31, 21/02/2019 [^] [^^] [^^^] [ответить] | –1 +/– |  Для проверки простых моделей сводящихся к утверждениям вида что-то одно всегда... текст свёрнут, показать | | |
| |
| |
| 11.38, PnDx (ok), 15:41, 21/02/2019 [^] [^^] [^^^] [ответить] | +1 +/– | Что, много букф По ссылке, внизу указатели на продолжение осмотра А то д... текст свёрнут, показать | | |
|
|
| 9.40, Ordu (ok), 19:53, 21/02/2019 [^] [^^] [^^^] [ответить] | +/– | Я не знаю что посоветовать Обычно в таких случаях люди рекомендуют всем повтори... большой текст свёрнут, показать | | |
|
| 8.31, Аноним (27), 09:12, 21/02/2019 [^] [^^] [^^^] [ответить] | –1 +/– | Гистограмма - это не график Это пары значений границы корзины - количество э... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 1.5, ryoken (ok), 11:53, 20/02/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
 Подскажите, кто в курсе. Сие только для x86\AMD64? На Power & K распространяется?
| | |
| |
| 2.10, solardiz (ok), 15:15, 20/02/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Пока только x86(-64), но поддержка других архитектур может быть добавлена при наличии спроса, особенно коммерческого (какой-нибудь "cloud" провайдер на Aarch64, какой-нибудь производитель телефонов на Android и т.п.) Причем добавлена она может быть легко, но частично (путем исключения специфичной для x86(-64) функциональности при сборке под другие архитектуры) или сложно, но полностью (путем добавления аналогичной функциональности для конкретных других архитектур). Вот ответ Адама на схожий вопрос: https://www.openwall.com/lists/lkrg-users/2018/07/31/3
| | |
| |
| 3.43, qweo (?), 13:54, 23/07/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Частичная поддержка мониторинга целостности лучше всё-таки, чем никакой. И, если это и правда несложно, то можно добавить поддержку POWER хотя бы?
В любом случае, спасибо за вашу работу!
| | |
| |
| 4.44, solardiz (ok), 15:42, 23/07/2019 [^] [^^] [^^^] [ответить]
| +/– |
Вы будете использовать LKRG на POWER, если мы добавим поддержку? Можете рассказать подробнее? В любом случае, боюсь Адаму будет негде это тестировать, кроме как в QEMU. Так что пока вот добавили AArch64, может быть добавим 32-битный ARM.
| | |
| |
| 5.45, qweo (?), 22:57, 23/07/2019 [^] [^^] [^^^] [ответить]
| +/– |
На одной из железок https://www.raptorcs.com/content/base/products.html (наверное, подожду рабочей станции на POWER10, но, может, и Blackbird возьму). Машины достаточно мощные, и думаю, что сервера на них обретут ограниченную популярность.
А так, я бы использовал и на MIPS, и на SPARC,но это специфично и едва ли интересно тем, у кого нет Yeelong и Ultra.
Кстати, интересно, как архитектура повлияет на производительность. Надеюсь, что накладные расходы останутся низкими.
| | |
|
|
|
|
| |
| 2.9, solardiz (ok), 15:03, 20/02/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
Илья молодец, спасибо ему. Я только что прокомментировал новые обходы там дальше по треду: думаю, нам надо будет считать такие обходы выходящими за рамки предоставляемой LKRG защиты как минимум на системах/VM'ах без SMEP, а также усилить защиту бита SMEP (пока что очень слабую). Любопытно, что сегодня же Kees Cook предложил в upstream-ядрах устранить gadget, типично используемый эксплойтами (в том числе этим) для выключения SMEP. Может быть, LKRG привнесет аналогичное изменение и в старые ядра.
| | |
|
| 1.28, Аноним (27), 00:25, 21/02/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
solardiz, вижу https вы таки наладили. Спасибо. А планируются ли оффициальные пакеты?
| | |
| |
| 2.34, solardiz (ok), 15:09, 21/02/2019 [^] [^^] [^^^] [ответить]
| +/– |
Бинарные пакеты LKRG, если когда-либо будут, скорее всего окажутся специфичными для конкретных версий конкретных дистрибутивов, а возможно и для конкретных сборок ядра. В ближайших планах их нет, но есть вариант в отдаленном будущем сделать такие сборки под какие-нибудь enterprise'ные дистрибутивы в платном LKRG Pro - как способ финансирования проекта, не связанный с каким-либо урезанием функциональности бесплатного LKRG и позволяющий использовать свободную лицензию (сейчас это GPLv2) и для LKRG Pro (который в таком случае будет лишь проверенной нами сборкой LKRG). Нужны ли бинарные пакеты кроме как под enterprise дистрибутивы и бесплатно? Какие, кому и зачем, учитывая разнообразие версий и сборок ядер, которые нам пришлось бы поддерживать? Пока нам представляется проще нынешний вариант, когда пользователь дает команду make сам и получает сборку под своё ядро. В этом контексте, мы также рассматриваем добавление рандомизации при сборке, что даст пользовательским сборкам некоторое преимущество по безопасности перед заранее подготовленными и у всех одинаковыми пакетами.
| | |
| |
| 3.41, J.L. (?), 12:39, 22/02/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Бинарные пакеты LKRG, если когда-либо будут, скорее всего окажутся специфичными для конкретных
> версий конкретных дистрибутивов, а возможно и для конкретных сборок ядра.
> разнообразие версий и сборок ядер, которые нам пришлось бы поддерживать
а dkms использовать?
| | |
| |
| 4.42, solardiz (ok), 16:01, 25/02/2019 [^] [^^] [^^^] [ответить]
| +/– |
Спасибо. Мы пока не рассматривали вариант использовать DKMS, но может быть.
| | |
|
|
|
| 1.32, Онанимус (?), 10:47, 21/02/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Когда в прошлом году я пробовал LKRG на своем ноуте, то он начинал с материться про взлом поле выхода ноута из спящего режима. Как с этим в новой версии? У меня, к сожалению, сейчас нет времени для теста (
| | |
| |
| 2.37, solardiz (ok), 15:33, 21/02/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Знаем об этой проблеме. Проявляется не на всяком железе, что усложняет проверку возможных исправлений. Пока не исправили. Когда исправим, напишем об этом в CHANGES.
| | |
|
|
