linux-kernel - Re: [PATCH] panic: Ensure preemption is disabled during panic()

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: <20191004111521.y6iera4eico6ezfq@pathway.suse.cz>
Date:   Fri, 4 Oct 2019 13:15:21 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Will Deacon <will@...nel.org>
Cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Kees Cook <keescook@...omium.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Feng Tang <feng.tang@...el.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-arm-kernel@...ts.infradead.org,
        Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, contact@...ium.me
Subject: Re: [PATCH] panic: Ensure preemption is disabled during panic()

On Fri 2019-10-04 11:49:48, Will Deacon wrote:
> On Fri, Oct 04, 2019 at 10:29:17AM +0100, Russell King - ARM Linux admin wrote:
> > On Fri, Oct 04, 2019 at 11:11:42AM +0200, Petr Mladek wrote:
> > > On Thu 2019-10-03 21:56:34, Will Deacon wrote:
> > > > I've deliberately left the irq part alone, since I think
> > > > having magic sysrq work via the keyboard interrupt is desirable from the
> > > > panic loop.
> > > 
> > > I agree that we should keep sysrq working.
> > > 
> > > One pity thing is that led_panic_blink() in
> > > leds/drivers/trigger/ledtrig-panic.c uses workqueues:
> > > 
> > >   + led_panic_blink()
> > >     + led_trigger_event()
> > >       + led_set_brightness()
> > > 	+ schedule_work()
> > > 
> > > It means that it depends on the scheduler. I guess that it
> > > does not work in many panic situations. But this patch
> > > will always block it.
> > > 
> > > I agree that it is strange that userspace still works at
> > > this stage. But does it cause any real problems?
> > 
> > Yes, there are watchdog drivers that continue to pat their watchdog
> > after the kernel has panic'd.  It makes watchdogs useless (which is
> > exactly how this problem was discovered.)
> 
> Indeed, and I think the LED blinking is already unreliable if the
> brightness operation needs to sleep. For example, if the kernel isn't
> preemptible or the work gets queued up on a different CPU which is
> sitting in panic_smp_self_stop().

To make it clear. I do not want to block this patch. I just wanted
to point out the problem. I am not sure how the blinking is important
these days. Well, I could imagine that it might be useful on some
embedded devices.

Another question is how many people want to end up with dead system
these days. The watchdogs are likely used in data centers. I guess
that automatic reboot in panic() is a better choice there.

Anyway, it might make sense to remove the panic blinking code when
it will not have a chance to work.

Best Regards,
Petr