Почему нельзя пропатчить целые ядра?
Это подстановка команд синтаксис. Он берет команду в круглых скобках, запускает ее, затем берет вывод (стандартный вывод )этой команды и заменяет его в этой части командной строки. Сложность в том, чтобы полагаться на него в этом примере, двоякая:
- поскольку он не заключен в кавычки, результаты будут подвержены расширению имени файла (поэтому, если какая-либо часть example.txt содержит шаблон, соответствующий существующим именам файлов, вы получите эти имена файлов вместо шаблона/строки ), и
- результаты разбиваются на слова в соответствии с переменной $IFS. Если example.txt содержит имя файла типа «a filename.txt», то внешний цикл
forувидит два параметра--aиfilename.txtи, вероятно, сделает не то.
Вы часто видите этот пример, поскольку люди полагаются на то, что содержимое example.txt не содержит шаблонов имен файлов или пробелов (или табуляции ).
Результатом этого однострочника является перебор предполагаемых доменных имен в example.txt и поиск по ним DNS.
Нам нравится думать о запуске программ как о статическом исходном коде, который их создает. Но они действительно постоянно меняются. Точно так же ядро в памяти НЕ совпадает с ядром на диске.
Цитировать Дийкстру в его письме "гото считал вредным "...
My first remark is that, although the programmer's activity ends when he has constructed a correct program, the process taking place under control of his program is the true subject matter of his activity, for it is this process that has to accomplish the desired effect; it is this process that in its dynamic behavior has to satisfy the desired specifications. Yet, once the program has been made, the "making' of the corresponding process is delegated to the machine.
My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible
Из этого я бы сделал вывод, что держать в памяти программу или ядро, которые не являются результатом загрузки ядра с диска, — плохая идея. Если ничего другого, вы хотите знать, что вы можете перезагрузиться и в итоге получить то же ядро, что и сейчас.
Как системный администратор -вы хотите знать, что в конце концов вы получили добросовестное обычное ядро, а не какое-то чудовище Франкенштейна, потому что ваше живое ядро имело тонкие отличия от того, которое они исправляли.
И патчить в реальном времени действительно очень сложно. Технически невозможно автоматически генерировать живые патчи
.Важно понимать, что программный код эффективно перезаписывает сам себя.
int X = 10;
void run(){
X=5;
}
В этом примере кода X=10никогда не выполняется как код. Число 10помещается компилятором в позицию «X». Когда 3-я строка выполняется во время выполнения, она заменяет значение в ячейке «X». Он буквально перезаписывает значение, то есть число 10полностью исчезает из работающего программного кода.
Теперь мы пытаемся исправить это с помощью:
int X = 20;
void run(){
X=15;
}
Что нужно пропатчить X до 20 или 15? Должны ли мы его вообще исправлять или просто оставить? Здесь мы не просто меняем код, мы меняем динамически генерируемые значения. Вы можете подумать, что, поскольку они генерируются динамически, вам может не понадобиться их изменять, но если мы их не изменим, знаем ли мы, что 5 или 10 по-прежнему допустимое значение в новом коде? Это не может быть сделано автоматически!
Короче говоря, существуют методы с соответствующими инструментами, которые могут создавать оперативные исправления, но для их использования и проверки результатов требуются специалисты.Выпуск этих инструментов и ожидание того, что домашние пользователи поймут, как их использовать, — хороший способ для многих домашних пользователей испортить свою систему.
Ядро является сердцем *операционной системы на базе nix. Он контролирует все поведение операционной системы. Следовательно, исправление в реальном времени помешает текущим текущим операциям. По этой причине его нельзя пропатчить вживую.
Любой механизм, который может быть использован во благо для внесения исправлений в работающее ядро, также может быть использован во зло, чтобы внедрить руткит в работающее ядро.
Если вредоносный код внедряется через подходящую уязвимость другого -уровня сети, может вообще не быть локальных измененных файлов, которые могли бы служить доказательством вторжения.
Кроме того, такие вещи, как адрес ядра -рандомизация пространства (KASLR ), призванные усложнить атаки на ядро, также усложняют оперативное исправление, так как информация, которую оно пытается защитить (адреса различных подпрограмм ядра в памяти )также являются информацией, необходимой для успешного оперативного исправления. Возможно, можно разумно управлять информацией, чтобы она была доступна только для законных целей, но я ожидаю, что это будет сложной проблемой.
В современных принципах проектирования «облачных» приложений упор делается на виртуализацию, параллелизм и несколько небольших серверов вместо одного большого.так что, возможно, время безотказной работы отдельных серверов становится менее важным, чем раньше? Если архитектура приложения включает набор из нескольких серверов со сбалансированной нагрузкой -, а размер набора является переменным, вы можете просто запустить новый уже исправленный -виртуальный сервер и отключить старый неисправленный, а затем повторять это до тех пор, пока все сервера заменены на обновленные. Если вы можете сделать это на всех уровнях вашего стека приложений, вам вообще не понадобится живое патчирование, так как проблема решается другим способом.