Linux вызвать kernel panic
Обновлено: 06.07.2024
1) Берем ноутбук (в моем случае EeePC 1000H)
2) Много раз подряд нажимаем кнопку включения/выключения Wi-Fi (в моем случае Fn+F2)
3) Любуемся.
PS: а еще после очередного обновления у меня перестал работать гибернейт.
Что сказать то хотел?
Там не обнуляется счётчик включений и на 4294967296-ом нажатии он падает с ошибкой?
Нет, достаточно нажать всего раз пять.
Ну запости в багтрекер, чо
> PS: а еще после очередного обновления у меня перестал работать гибернейт.
а на винде, такое работает?
что ты разнылся как баба? исправь багу и вышли патч, будь мужиком.
судя по звездам он тут давно ))
Смех смехом, но у меня такая лажа была на 3945 под вендой когда-то. А сейчас нет под Линуксом.
Что побудило тебя много раз подряд нажимать на кнопку включения вафли?
Желание написать нытик-тред на ЛОР, это же очевидно. С бабами, видимо, всё хорошо или наоборот никак, чтобы было что про них писать.
> Что побудило тебя много раз подряд нажимать на кнопку включения вафли?
Показалось, что не сработало с первого раза, нажал второй. Оказалось, что сработало с первого, пришлось нажать еще. Трех раз тогда хватило.
> Ну запости в багтрекер, чо
Да как бы уже пишу (:
Видимо сеё работает исключительно в в школьном поделии арчика.немудренно. P.S в убунте и дебияне УМВР
И где вы их находите? Ни разу в жизни не видел настоящей CP ('VFS not syncing', говорят, не считается).
> судя по звездам
ЛОРовская астрология :-)
Кстати не уверен, паник это или просто какой-нибудь oops, но система ни на что не реагирует после этого.
>И где вы их находите? Ни разу в жизни не видел настоящей CP ('VFS not syncing', говорят, не считается).
> Кстати не уверен, паник это или просто какой-нибудь oops, но система ни на что не реагирует после этого.
В панике система должна светодиодами клавиатурными моргать по идее.
Лицоладонь. Правда, я подозревал, что сокращение CP может быть истолковано неоднозначно :)
Так а что ты имел ввиду? Cernel Panic?
Охтыж. Выходит, да. Хорошо ступил %)
Child pr0n же. Что же еще?
Палишься, видимо :D
не работает на асусе к40ин :З
плохой баг нашел
Хм, интересно. Тогда жду, пока кто-нибудь с подобным нетбуком не появится.
моей дочке нравятся мигающие кнопочки на ноуте, собственно этот баг она уже протестила на двух ноутах еще раньше. баг не обнаружен.
Хм.. у меня тоже самое на арче на EeePC 1000 - несколько раз выключал и включал вай-фай (Fn+F2) и 3 раза ловил кернел паник (именно кернел паник). Но было это месяц-два назад. Щас проверил - не воспроизводиться.
А оно когда как, иногда срабатывает, а иногда нет.
hp mini 311 хватает 3х раз обычно.. только не кернел паник, а полное зависание с тишиной в логах(((
Только что проверил - раз 20-30 понажимал - не роботает. Arch 2.6.38, Дрова пропиетарные, ибо синезуб нужен.
30 раз нажал, ничего не произогло
eMashines D520, Wifi от Atheros
>Ни разу в жизни не видел настоящей CP
Спасибо, Евгений Ваганович, но я не любитель этой гадости.
Апдейты - это зло.
Не работает. Asus EEE PC T91, Kubuntu 11.04
Нетбуки мне кажется похожие.
> Еще один способ вызвать кернел паник
У вас archlinux.
> полное зависание с тишиной в логах
У меня во время этого зависания на экран вываливается длинный текст, похожий на тот, что бывает при панике. В логах да, конечно же, ничего нет.
попробуй поставить на свой комп MacOSX, да не хакерскую сборочку, а самому. Навидаешься по нехочу.
текста нет, на экране застывает последнее изображение до зависания. печаль в общем(((
Кстати, оказывается этот баг уже зарепорчен давно:
Если это конечно оно. Но по симптомам похоже.
Lenovo thinkpad edge не помню какой, тот что с интелом двухядерным и небольшим экраном (не люблю большие ноуты таскать) - после обновлений рандомно что то отваливается, после сна через раз kernel panic - так что не удивил.
У меня ещё бывает биос в панику выпадает (загораются все лампочки, а экран нет) при просыпании, после этого часы начинают ровно на 30000 секунд отставать, мистика вообщем.
Часто встречающаяся ситуация: виртуальный или аппаратный сервер завис и не отвечает. Заходите на него с помощью инструмента удаленного управления IPMI или консоли VNC, видите только черный экран и ничего кроме. Скорее всего, ядро Linux вошло в режим паники (Kernel Panic), который вызван сбоем одного из модулей ядра, ошибкой в самом ядре, критической аппаратной ошибкой.
Метод не очень широко известен, но чрезвычайно полезен для полноценной диагностики серверов Linux, когда их ядро сталкивается с ситуациями, последствием которых является переход в режим паники с остановкой всех сервисов.
Все примеры в данной статье будут приводиться для серверов, работающих под управлением Ubuntu Linux, однако, для других дистрибутивов настройка практически полностью повторяется.
В рамках инструкции будем использовать два сервера:
На сервере panic мы настроим netconsole и будем имитировать ситуацию паники ядра. На сервере monitor мы настроим rsyslogd для поддержки удаленного журналирования по протоколу udp. Начнем с настройки узла monitor.
Настройка Rsyslog на узле monitor
Сохраните файл и перезапустите rsyslogd:
убедимся, что rsyslog слушает порт 514 по протоколу UDP:
Настройка практически завершена, однако, так как при использовании удаленного журналирования отсутствуют встроенные механизмы верификации источника данных, подходящие при использовании netconsole, мы будем использовать iptables для ограничения трафика от неизвестных источников.
Настройка Iptables на узле monitor
Установим пакет iptables-persistent.
Если вы предпочитаете для настройки использовать UFW, можете использовать этот инструмент. Мы подразумеваем, что используются настройки iptables, по умолчанию пропускающие весь трафик, поэтому будем использовать запрещающие правила.
Добавим сохранение правил в iptables-persistent:
Если вы используете приложения, которые добавляют свои правила, например, fail2ban или docker, удалите правила этих приложений из созданных файлов /etc/iptables/rules.v4, /etc/iptables/rules.v6. Например, для fail2ban необходимо удалить правила:
Для проверки корректности настроек перезагрузите сервер monitor и после завершения загрузки проверьте наличие в iptables всех нужных правил с помощью команд iptables-save и ip6tables-save:
На этом настройку хоста monitor считаем законченной. Перейдем к настройке хоста panic.
Настройка модуля netconsole на узле panic
В документации ядра Linux к модулю netconsole можно увидеть, что модуль принимает следующие настройки:
разберем каждую из них:
как можно видеть, параметры, кроме tgt-ip опциональны, но мы зададим их все для большей ясности.
После выполнения этих операций загрузим модуль в память:
На этом настройка модуля завершена. Убедимся в том, что он работает. Для этого смоделируем событие паники ядра. Сначала запустим отслеживание событий syslog в режиме реального времени на сервере monitor:
В журнале вы должны увидеть строку, похожую на эту:
Если вы видите такой вывод, значит настройка успешна и при возникновении исключительных событий ядра, вы сможете видеть их в журнале syslog на удаленном сервере.
Заключение
Работа операционной системы должна быть полностью «Синхронизирована» с оборудованием, включая в себя аудио- и видеоподключение с помощью драйверов, беспроводного соединения и других аппаратных параметров для подключения оборудования и программного обеспечения.
Эти подключения, иногда, могут не очень хорошо работать, а иногда ваша система вообще может выйти из строя, и вы потеряете важные данные. В этой статье я расскажу о Kernel Panic(Панике ядра), которая является сбоем системы в Linux.
Что такое Kernel Panic?
Но, как насчет Kernel Panic? Вы слышали это имя раньше?
Паника ядра обычно возникает тогда, когда не удалось запустить init, так как, несмотря на запущенное и работоспособное ядро, сама система остаётся непригодной к дальнейшей работе
Также, при этой функции создаются логи, сообщающие об ошибках. Эта информация может быть полезна техникам для отладки, но ее трудно понять для неопытных пользователей.
Возможные причины для Kernel Panic
Способы избежать паники ядра
Обычно Kernel Panic происходит не так часто, и на самом деле довольно редко(за исключением Windows пользователей). Чтобы избежать паники ядра, вы должны четко знать технические характеристики вашего компьютера, а не просто установить новую память с любыми частотами. А чтобы не было системной паники, вы должны постоянно обновлять свою систему
Вывод
Linux хорошая система, но есть вещи, с которыми даже дистрибутивы Linux часто встречаются, это ошибки, которые представляют собой системный или аппаратный сбой. Даже при том, что это происходит, по крайней мере, мы можем видеть причину сбоя, но, как было сказано ранее, логи ошибок более понятны экспертам, чем обычным пользователям.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Чтобы выполнить все задуманное, нам понадобятся следующие утилиты:
- GCC — компилятор C, чтобы компилировать ядро;
- GDB — отладчик, который нам пригодится, чтобы отлаживать ядро;
- BC — будет нужен для сборки ядра;
- Make — обработчик рецептов сборки ядра;
- Python — интерпретатор языка Python, он будет использоваться модулями GDB;
- pacstrap или debootstrap — скрипты для развертки системы. Будут нужны, чтобы собрать rootfs;
- любой текстовый редактор (подойдет Vim или nano), чтобы написать модуль и рецепт к нему;
- qemu-system-x86_64 — виртуальная машина, с помощью которой мы будем запускать ядро.
Этого вполне достаточно, чтобы собрать ядро и проэксплуатировать его модуль, содержащий уязвимость.
В целях эксперимента нам понадобится ядро Linux, которое придется самостоятельно собрать.
Конфигурация
Мы не будем делать универсальное ядро, которое может поднимать любое железо. Все, что нам нужно, — это чтобы оно запускалось в QEMU, а изначальная конфигурация, предложенная разработчиками, для этих целей подходит. Однако все‑таки необходимо удостовериться, что у нас будут символы для отладки после компиляции и что у нас нет стековой канарейки (об этой птице мы поговорим позже).
Существует несколько способов задать правильную конфигурацию, но мы выберем menuconfig . Он удобен и нетребователен к GUI. Выполняем команду make menuconfig и наблюдаем следующую картину.
Главное меню menuconfig
Для того чтобы у нас появились отладочные символы, идем в секцию Kernel hacking → Compile-time checks and compiler options. Тут надо будет выбрать Compile the kernel with debug info и Provide GDB scripts for kernel debugging. Кроме отладочных символов, мы получим очень полезный скрипт vmlinux-gdb. py . Это модуль для GDB, который поможет нам в определении таких вещей, как базовый адрес модуля в памяти ядра.
Включение символов отладки и vmlinux-gdb.py
Теперь надо убрать протектор стека, чтобы наш модуль был эксплуатируем. Для этого возвращаемся на главный экран конфигурации, заходим в раздел General architecture-dependent options и отключаем функцию Stack Protector buffer overflow detection.
Отключение стековой канарейки
Можно нажать на кнопку Save и выходить из окна настройки. Что делает эта настройка, мы увидим далее.
Сборка ядра
Тут совсем ничего сложного. Выполняем команду make -j< threads> , где threads — это количество потоков, которые мы хотим использовать для сборки ядра, и наслаждаемся процессом компиляции.
Компиляция ядра
Скорость сборки зависит от процессора: около пяти минут она займет на мощном компьютере и намного дольше — на слабом. Можешь не ждать окончания компиляции и продолжать читать статью.
Модуль ядра
В ядре Linux есть такое понятие, как character device. По‑простому, это некоторое устройство, с которым можно делать такие элементарные операции, как чтение из него и запись. Но иногда, как ни парадоксально, этого устройства в нашем компьютере нет. Например, существует некий девайс, имеющий путь / dev/ zero , и, если мы будем читать из этого устройства, мы получим нули (нуль‑байты или \ x00 , если записывать в нотации C). Такие устройства называются виртуальными, и в ядре есть специальные обработчики на чтение и запись для них. Мы же напишем модуль ядра, который будет предоставлять нам запись в устройство. Назовем его / dev/ vuln , а функция записи в это устройство, которая вызывается при системном вызове write , будет содержать уязвимость переполнения буфера.
Код модуля и пояснения
Создадим в папке с исходным кодом ядра вложенную папку с именем vuln , где будет находиться модуль, и поместим там файл vuln. c вот с таким контентом:
Читайте также: