BUG: kernel NULL pointer dereference

safocl	# 3 года, 3 месяца назад (отредактировано 3 года, 3 месяца назад)
Темы: 122 Сообщения: 1571 Участник с: 08 октября 2015	имеется арч, i3wm, i5 3330, nvidia gtx 1650, drivers nvidia 460.27 на радостях обновился до беты через АУР... но во время поигрывания в европку комп просто завис и не реагировал ни на что -- даже на alt+ctrl+Fx после ребута прочел логи и чот я снова думаю чо енто все нвидиа драйвер виновен... кто нить может объяснить чо там произошло по логам? -- то что какая то ошибка связанная с разыменованием нулевого указателя я и так понял из логов... но как она привела к таким последствиям?

# 3 года, 3 месяца назад (отредактировано 3 года, 3 месяца назад)

Сообщения: 1571

Участник с: 08 октября 2015

имеется арч, i3wm, i5 3330, nvidia gtx 1650, drivers nvidia 460.27
на радостях обновился до беты через АУР...

но во время поигрывания в европку комп просто завис и не реагировал ни на что -- даже на alt+ctrl+Fx

после ребута прочел логи и чот я снова думаю чо енто все нвидиа драйвер виновен...
кто нить может объяснить чо там произошло по логам? -- то что какая то ошибка связанная с разыменованием нулевого указателя я и так понял из логов... но как она привела к таким последствиям?

vasek	# 3 года, 3 месяца назад
Темы: 47 Сообщения: 11742 Участник с: 17 февраля 2013	safocl думаю чо енто все нвидиа драйвер виновен… Ясно одно, что перед ошибкой вызывалась функция/модуль nvidia. Что там произошло конкретно, нужно смотреть дамп падения, а это, считай, не возможно. Можно еще отметить, что ошибка в user space (ядро не при делах) и что то там не понятное с процессом PID=769, для работы с которым и вызывался модуль nvidia. Раз получил OOPS, нужно было выжать максимум информации из этого (распределение памяти, список процессов, зависшие процессы), хотя бы мог оцениться, что это за процесс PID=769. PS - а вообще, рекомендую почитать расшифровку малых дампов OOPS, kernel panic Ошибки не исчезают с опытом - они просто умнеют

vasek

# 3 года, 3 месяца назад

Темы: 47

Сообщения: 11742

Участник с: 17 февраля 2013

safocl
думаю чо енто все нвидиа драйвер виновен…

Ясно одно, что перед ошибкой вызывалась функция/модуль nvidia. Что там произошло конкретно, нужно смотреть дамп падения, а это, считай, не возможно.
Можно еще отметить, что ошибка в user space (ядро не при делах) и что то там не понятное с процессом PID=769, для работы с которым и вызывался модуль nvidia.
Раз получил OOPS, нужно было выжать максимум информации из этого (распределение памяти, список процессов, зависшие процессы), хотя бы мог оцениться, что это за процесс PID=769.

PS - а вообще, рекомендую почитать расшифровку малых дампов OOPS, kernel panic

Ошибки не исчезают с опытом - они просто умнеют

nafanja	# 3 года, 3 месяца назад
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	а на стандартном ядре и на лтс, ошибка тоже появляется? Псевдографический инсталлятор Arch Linux ver. 3.8.2 Благодарности принимаются на ЯД 410012815723874

vasek	# 3 года, 3 месяца назад (отредактировано 3 года, 3 месяца назад)
Темы: 47 Сообщения: 11742 Участник с: 17 февраля 2013	Сначала тоже подумал на ядро (linux-zen), но больше склоняюсь, что к этому имеет отношение supervisor. При нормальном малом дампе обычно сразу после строки BUG должна идти строка с указанием IP (указатель инструкции в момент неисправности), типа такого (осталось из старых логов) `[ 31.659749] BUG: unable to handle kernel NULL pointer dereference at (null) [ 31.662668] IP: [<ffffffff8139f166>] sysrq_handle_crash+0x16/0x20 [ 31.662668] PGD 3bfb9067 PUD 368a7067 PMD 0 [ 31.662668] Oops: 0002 [#1] SMP` а у safocl картинка другая `kernel: BUG: kernel NULL pointer dereference, address: 0000000000000020 kernel: #PF: supervisor read access in kernel mode kernel: #PF: error_code(0x0000) - not-present page kernel: PGD 8000000212141067 P4D 8000000212141067 PUD 20507d067 PMD 0 kernel: Oops: 0000 [#1] PREEMPT SMP PTI` правда никогда не приходилось анализировать с этим supervisor - может оно так и должно быть .... А вообще зачем нужен этот supervisor ??? Ошибки не исчезают с опытом - они просто умнеют

vasek

# 3 года, 3 месяца назад (отредактировано 3 года, 3 месяца назад)

Темы: 47

Сообщения: 11742

Участник с: 17 февраля 2013

Сначала тоже подумал на ядро (linux-zen), но больше склоняюсь, что к этому имеет отношение supervisor.
При нормальном малом дампе обычно сразу после строки BUG должна идти строка с указанием IP (указатель инструкции в момент неисправности), типа такого (осталось из старых логов)

[   31.659749] BUG: unable to handle kernel NULL pointer dereference at           (null)
[   31.662668] IP: [<ffffffff8139f166>] sysrq_handle_crash+0x16/0x20
[   31.662668] PGD 3bfb9067 PUD 368a7067 PMD 0
[   31.662668] Oops: 0002 [#1] SMP

а у safocl картинка другая

kernel: BUG: kernel NULL pointer dereference, address: 0000000000000020
kernel: #PF: supervisor read access in kernel mode
kernel: #PF: error_code(0x0000) - not-present page
kernel: PGD 8000000212141067 P4D 8000000212141067 PUD 20507d067 PMD 0
kernel: Oops: 0000 [#1] PREEMPT SMP PTI

правда никогда не приходилось анализировать с этим supervisor - может оно так и должно быть ....
А вообще зачем нужен этот supervisor ???

Ошибки не исчезают с опытом - они просто умнеют

safocl	# 3 года, 3 месяца назад
Темы: 122 Сообщения: 1571 Участник с: 08 октября 2015	vasek А вообще зачем нужен этот supervisor ??? если чесна я ваще не понимаю чо тут имеется ввиду под супервизором. nafanja а на стандартном ядре и на лтс, ошибка тоже появляется? я хз -- но енто именно после обновы дров так крашнулась система -- проявлялось ентот единственный раз за несколько дней всего. Посему о воспроизводимости говорить низя -- но склоняюся к ошибке в драйвере нвидии... -- все же после обновы его так всутулилося...

safocl

# 3 года, 3 месяца назад

Темы: 122

Сообщения: 1571

Участник с: 08 октября 2015

vasek
А вообще зачем нужен этот supervisor ???

если чесна я ваще не понимаю чо тут имеется ввиду под супервизором.

nafanja
а на стандартном ядре и на лтс, ошибка тоже появляется?

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

vasek	# 3 года, 3 месяца назад (отредактировано 3 года, 3 месяца назад)
Темы: 47 Сообщения: 11742 Участник с: 17 февраля 2013	safocl если чесна я ваще не понимаю чо тут имеется ввиду под супервизором. Разобрался: просто давно не видел дамп OOPS новых cpu …. строчка в логе `supervisor read access in kernel mode` говорит о том, что твой cpu имеет технологию SMAP (Supervisor Mode Access Prevention) - проверить можно по наличию флага в выводе `grep --color=auto smap /proc/cpuinfo` EDIT 1 - в части safocl но склоняюся к ошибке в драйвере нвидии… – все же после обновы его так всутулилося… не все так однозначно - прямого бага в драйвере может и не быть, а вот иметь косвенное отношение к OOPS вполне может. Как пишут в DOC: `... вполне возможно, что недавно выгруженный модуль не очистился и оставил некоторый остаток (например, таймер или обратный вызов) в ядре - что является классическим случаем для oops или паники` А последним выгруженным модулем, согласно логу, и был модуль nvidia. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 3 года, 3 месяца назад (отредактировано 3 года, 3 месяца назад)

Темы: 47

Сообщения: 11742

Участник с: 17 февраля 2013

safocl
если чесна я ваще не понимаю чо тут имеется ввиду под супервизором.

Разобрался: просто давно не видел дамп OOPS новых cpu …. строчка в логе

supervisor read access in kernel mode

говорит о том, что твой cpu имеет технологию SMAP (Supervisor Mode Access Prevention) - проверить можно по наличию флага в выводе

grep --color=auto smap /proc/cpuinfo

EDIT 1 - в части

safocl
но склоняюся к ошибке в драйвере нвидии… – все же после обновы его так всутулилося…

не все так однозначно - прямого бага в драйвере может и не быть, а вот иметь косвенное отношение к OOPS вполне может. Как пишут в DOC:

 ... вполне возможно, что недавно выгруженный модуль не очистился и оставил некоторый остаток (например, таймер или обратный вызов) в ядре - что является классическим случаем для oops или паники

А последним выгруженным модулем, согласно логу, и был модуль nvidia.

Ошибки не исчезают с опытом - они просто умнеют

safocl	# 3 года, 3 месяца назад
Темы: 122 Сообщения: 1571 Участник с: 08 октября 2015	vasek говорит о том, что твой cpu имеет технологию SMAP (Supervisor Mode Access Prevention) - проверить можно по наличию флага в выводе -- нету такого вроде ... vasek А последним выгруженным модулем, согласно логу, и был модуль nvidia. ааа ну вот енто я думаю может и было... пока больше трабблов нету вроде...

safocl

# 3 года, 3 месяца назад

Темы: 122

Сообщения: 1571

Участник с: 08 октября 2015

vasek
говорит о том, что твой cpu имеет технологию SMAP (Supervisor Mode Access Prevention) - проверить можно по наличию флага в выводе

-- нету такого вроде ...

vasek
А последним выгруженным модулем, согласно логу, и был модуль nvidia.

ааа ну вот енто я думаю может и было... пока больше трабблов нету вроде...

vasek	# 3 года, 3 месяца назад (отредактировано 3 года, 3 месяца назад)
Темы: 47 Сообщения: 11742 Участник с: 17 февраля 2013	safocl нету такого вроде … Вполне возможно, что данный флаг не высвечивается, нужно смотреть полный вывод cpuid -1 \| grep -i SMAP `SMAP: supervisor mode access prevention = false` даже стало интересно - что там у тебя покажет PS - cpuid в AUR, но если стоит пакет msr-tools, то нужно его удалить EDIT 1 - не обязательно SMAP, а что то другое, связанное с supervisor, например, SMEP cpuid -1 \| grep -i smep `SMEP supervisor mode exec protection = false` Ошибки не исчезают с опытом - они просто умнеют

vasek

# 3 года, 3 месяца назад (отредактировано 3 года, 3 месяца назад)

Темы: 47

Сообщения: 11742

Участник с: 17 февраля 2013

safocl
нету такого вроде …

Вполне возможно, что данный флаг не высвечивается, нужно смотреть полный вывод
cpuid -1 | grep -i SMAP

      SMAP: supervisor mode access prevention  = false

даже стало интересно - что там у тебя покажет

PS - cpuid в AUR, но если стоит пакет msr-tools, то нужно его удалить

EDIT 1 - не обязательно SMAP, а что то другое, связанное с supervisor, например, SMEP
cpuid -1 | grep -i smep

      SMEP supervisor mode exec protection     = false

Ошибки не исчезают с опытом - они просто умнеют

safocl	# 3 года, 3 месяца назад
Темы: 122 Сообщения: 1571 Участник с: 08 октября 2015	vasek cpuid -1 \| grep -i SMAP -- как то так...

vasek	# 3 года, 3 месяца назад (отредактировано 3 года, 3 месяца назад)
Темы: 47 Сообщения: 11742 Участник с: 17 февраля 2013	Ну вот, оказался прав. Но по идее должно сработать и grep --color=auto smep /proc/cpuinfo , но cpuid мне нравится больше, хотя это дело вкуса. Ядро поддерживает эти технологии smap и smep , а если их поддерживает и cpu, то их можно и отключить, используя опции: nosmap, nosmep - отключив тем самым режим supervisor .... можешь поэкспериментировать в части изменения быстродействия ... ломать тебя вряд ли кто будет. PS - не исключаю, что этот supervisor имел какое то отношение к OOPS ... что то пошло не так с областями памяти kernel и userspace SMEP (Supervisor Mode Execution Prevention — предотвращение исполнения кода в режиме супервизора) - это технология, разработанная компанией Intel для защиты компьютера от хакерских атак и других угроз, использующих так называемый "режим супервизора". Режим супервизора – это привилегированный режим работы процессора, который используется ядром операционной системы. Этот режим также называют режимом ядра. Противоположным ему является режим пользователя, в котором работают пользовательские приложения. Используя уязвимости режима ядра, опытный хакер способен получить полный контроль над системой. Но если на компьютере используется SMEP, пользовательские приложения теряют возможность выполнять привилегированные операции, например, получать доступ к портам ввода-вывода, управляющим регистрами процессора, и др. Кроме того, память, используемая в режиме ядра, защищается от доступа из пользовательского режима. Любая попытка выполнить код, находящийся в памяти пользовательского приложения, приводит к ошибке страницы и компьютер "выпадает" в синий экран смерти (так и не выполнив требуемые атакующему действия). EDIT 1 - сразу уж добавлю отличие smep от smap - пусть все будет в одном месте SMEP хотя и значительно усложняет задачу взлома системы, все же не гарантирует полной ее защиты. Поэтому позже (в процессорах архитектуры Broadwell) в целях повышения безопасности и защиты от уязвимостей, не устраненных SMEP, дополнительно была внедрена технология SMAP (Supervisor Mode Access Prevention). Она предотвращает запись в память и чтение из нее кода, несанкционированно использующего режим супервизора, тогда как SMEP только предупреждает выполнение этого кода. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 3 года, 3 месяца назад (отредактировано 3 года, 3 месяца назад)

Темы: 47

Сообщения: 11742

Участник с: 17 февраля 2013

Ну вот, оказался прав. Но по идее должно сработать и grep --color=auto smep /proc/cpuinfo , но cpuid мне нравится больше, хотя это дело вкуса.
Ядро поддерживает эти технологии smap и smep , а если их поддерживает и cpu, то их можно и отключить, используя опции: nosmap, nosmep - отключив тем самым режим supervisor .... можешь поэкспериментировать в части изменения быстродействия ... ломать тебя вряд ли кто будет.

PS - не исключаю, что этот supervisor имел какое то отношение к OOPS ... что то пошло не так с областями памяти kernel и userspace

SMEP (Supervisor Mode Execution Prevention — предотвращение исполнения кода в режиме супервизора) - это технология, разработанная компанией Intel для защиты компьютера от хакерских атак и других угроз, использующих так называемый "режим супервизора".
Режим супервизора – это привилегированный режим работы процессора, который используется ядром операционной системы. Этот режим также называют режимом ядра. Противоположным ему является режим пользователя, в котором работают пользовательские приложения.
Используя уязвимости режима ядра, опытный хакер способен получить полный контроль над системой. Но если на компьютере используется SMEP, пользовательские приложения теряют возможность выполнять привилегированные операции, например, получать доступ к портам ввода-вывода, управляющим регистрами процессора, и др. Кроме того, память, используемая в режиме ядра, защищается от доступа из пользовательского режима.
Любая попытка выполнить код, находящийся в памяти пользовательского приложения, приводит к ошибке страницы и компьютер "выпадает" в синий экран смерти (так и не выполнив требуемые атакующему действия).

EDIT 1 - сразу уж добавлю отличие smep от smap - пусть все будет в одном месте

SMEP хотя и значительно усложняет задачу взлома системы, все же не гарантирует полной ее защиты. Поэтому позже (в процессорах архитектуры Broadwell) в целях повышения безопасности и защиты от уязвимостей, не устраненных SMEP, дополнительно была внедрена технология SMAP (Supervisor Mode Access Prevention). Она предотвращает запись в память и чтение из нее кода, несанкционированно использующего режим супервизора, тогда как SMEP только предупреждает выполнение этого кода.

Ошибки не исчезают с опытом - они просто умнеют