«Форсирование» паники ядра из терминала в Linux

Содержание

Вопрос или проблема
Ответ или решение
Есть несколько подходов для вызова Kernel Panic:
Важные аспекты:
Заключение

Вопрос или проблема

Я использую Solus 4.0 (в виртуальной машине) и пытаюсь делать скриншоты вывода “типичного” паникера ядра (“BSOD”). Система инициализации в Solus — systemd.

Я попробовал следующие команды в терминале безуспешно:

$ kill -6 1

Ничего не делает (нет эхо).

$ sudo kill -SEGV 1

Тоже ничего не делает…

# echo c > /proc/sysrq-trigger

Зависает система, но это не то, что мне нужно.

Какие-нибудь идеи?

Я хотел бы видеть стеки вызовов и всё такое. Дело не в зависании системы с помощью fork bomb.

Использованные ссылки:

Если вы хотите увидеть трассировки стека потоков, работающих на всех процессорах, вы можете

# echo l > /proc/sysrq-trigger

Согласно, например, Википедии это

Показывает трассировку стека для всех активных процессоров.

В идеале это вообще не должно быть возможно, иначе хакеры могли бы слишком легко вывести системы из строя. Если вы нашли способ сделать это, это может быть серьёзной проблемой безопасности.

Надёжный способ вызвать панику ядра из пользовательского пространства — заставить PID 1 завершить работу. Он защищён от сигналов, поэтому вам придётся использовать другой подход, например, отладку: sudo gdb -ex 'call _exit(0)' --pid=1 --batch

Ответ или решение

Для инициирования Kernel Panic на системе Solus 4.0 (которая работает как виртуальная машина с использованием init-системы systemd), существуют несколько методов, которые можно использовать из терминала. Kernel Panic, аналог синий экран смерти (BSOD) в Windows, может быть полезен для тестирования и диагностики.

Есть несколько подходов для вызова Kernel Panic:

Использование SysRq комманд:
Kernel Magic SysRq Key предоставляет набор функций для отладки и восстановления системы. Ваша команда echo c > /proc/sysrq-trigger инициирует Kernel Panic, однако, чтобы просмотреть стек вызовов, можно воспользоваться командой:
```
echo l > /proc/sysrq-trigger
```
Это действие отобразит стек вызовов для всех активных процессоров, что может предоставить полезную информацию для диагностики.
Управление PID 1:
PID 1, или systemd, является основным процессом и защищен от сигналов как SIGSEGV. Однако можно перейти другим путем, используя отладчик gdb:
```
sudo gdb -ex 'call _exit(0)' --pid=1 --batch
```
Этот метод принудительно завершает работу systemd, что приведет к Kernel Panic. При использовании данного подхода необходимо соблюдать осторожность, поскольку он приведет к немедленной нестабильности системы.
Инструменты для отладки и мониторинга:
Некоторые сторонние инструменты, созданные для отладки ядер, также могут содержать средства для инициирования Kernel Panic с предложением подробных данных о состоянии системы в момент сбоя.

Важные аспекты:

Безопасность: Доступ к таким методам должен быть строго ограничен, чтобы избежать использования в злонамеренных целях. Kernel Panic может использоваться злоумышленниками для нарушения работы систем, поэтому соответствующее разрешение и доступ к отладчикам должны быть защищены.
Контекст запуска и последствия: Во время отладки или тестирования в виртуальной среде имеет смысл сделать полную резервную копию системы или снапшот виртуальной машины, так как последствия Kernel Panic могут привести к потере данных.

Заключение

Каждая из вышеперечисленных команд требует высокого уровня привилегий и глубокого понимания работы системы. Использование данных методов в производственной среде требует особого внимания и только при крайней необходимости. Соблюдение стандартов безопасности и регулярное обновление системы останется лучшей практикой для снижения уязвимости системы.