linux-kernel - Re: [PATCH] kernel/reboot: enhance dmesg logging for system restart

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <066a05ca-e2e8-4cfe-8d33-60a665495cdf@quicinc.com>
Date: Wed, 19 Jun 2024 16:39:27 +0530
From: Faiyaz Mohammed <quic_faiyazm@...cinc.com>
To: 이동민 <ldmldm05@...il.com>
CC: <benjamin.bara@...data.com>, <dmitry.osipenko@...labora.com>,
        <lee@...nel.org>, <daniel.lezcano@...aro.org>,
        <j.granados@...sung.com>, <linux-kernel@...r.kernel.org>,
        <dongmin.lee@...ux.dev>
Subject: Re: [PATCH] kernel/reboot: enhance dmesg logging for system restart

Sorry for the delayed response.

On 6/7/2024 7:35 PM, 이동민 wrote:
> On Fri, Jun 7, 2024 at 7:59 PM Faiyaz Mohammed <quic_faiyazm@...cinc.com> wrote:
>>
>> It is useful to add the PID and Comm information along with command info.
>>
>> Currently, when system reboot kernel logs don not print PID and Comm:
>>
>> reboot: Restarting system with command 'reboot,scheduled_reboot'
>> reboot: Restarting system with command 'RescueParty'
>> reboot: Restarting system with command 'bootloader'
>> reboot: Restarting system with command 'recovery'
>> reboot: Restarting system with command 'userrequested,recovery’
>>
>> For Example after adding PID and Comm:
>>
>> reboot: PID: 1 Comm: init Restarting system with command 'shell'
>> reboot: PID: 1 Comm: init Restarting system with command 'bootloader'
> 
> Printing out PID and COMM information might be useful for getting
> which task is triggered system reboot. However, It's never a critical
> information that deserves printed with pr_emerg() to whoever want the
> system to be rebooted, unless the kernel is in a problematic
> situation.
> 
Agreed, It's not critical to print the process name which trigger reboot 
with pr_emerg(), so should it be OK if we add additional logging with 
reduced log level?

> If reboot is called by user space via reboot system call, reboot is
> never a problematic situation because it's user's intend in the
> kernel's view. Other kernel codes which invokes involuntary restart
> such as temperature overheat (drivers/memory/emif.c:622), already
> prints out the situation before invoking system_reboot(), hence, there
> is no reason to print out who called system_reboot().
> 
Agreed in kernel view user's space reboot is intended but if system is 
silently rebooting due to any user process(vendor specific user process 
or even a OS specific user deamon) meeting any error condition then a 
developer debugging the system need to know which user process is 
issuing reboot system call to debug further, so in humble opinion it is 
helpful for system debug perspective.

> Again, system reboot is not kernel panic, oops nor bug. If your intend
> is to debug the reboot handler's behavior more easily, just set a
> breakpoint for kernel_restart() function with gdb.
> 
> --
> Best Regards,
> Dongmin Lee
> 
> https://ldmsys.net/