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]
Date:   Wed, 26 Jan 2022 11:10:39 +0800
From:   Baoquan He <bhe@...hat.com>
To:     "Guilherme G. Piccoli" <gpiccoli@...lia.com>
Cc:     Masami Hiramatsu <mhiramat@...nel.org>,
        Petr Mladek <pmladek@...e.com>,
        HATAYAMA Daisuke <d.hatayama@...fujitsu.com>,
        kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
        dyoung@...hat.com, linux-doc@...r.kernel.org, vgoyal@...hat.com,
        stern@...land.harvard.edu, akpm@...ux-foundation.org,
        andriy.shevchenko@...ux.intel.com, corbet@....net,
        halves@...onical.com, kernel@...ccoli.net,
        Will Deacon <will@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Hidehiro Kawai <hidehiro.kawai.ez@...achi.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        John Ogness <john.ogness@...utronix.de>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Juergen Gross <jgross@...e.com>, mikelley@...rosoft.com
Subject: Re: [PATCH V4] notifier/panic: Introduce panic_notifier_filter

On 01/24/22 at 11:48am, Guilherme G. Piccoli wrote:
> On 24/01/2022 10:59, Baoquan He wrote:
> > [...]
> > About pre_dump, if the dump is crash dump, hope those pre_dump notifiers
> > will be executed under conditional check, e.g only if 'crash_kexec_post_notifiers'
> > is specified in kernel cmdline. 
> 
> Hi Baoquan, based on Petr's suggestion, I think pre_dump would be
> responsible for really *non-intrusive/non-risky* tasks and should be
> always executed in the panic path (before kdump), regardless of
> "crash_kexec_post_notifiers".
> 
> The idea is that the majority of the notifiers would be executed in the
> post_dump portion, and for that, we have the
> "crash_kexec_post_notifiers" conditional. I also suggest we have
> blacklist options (based on function names) for both notifiers, in order
> to make kdump issues debug easier.
> 
> Do you agree with that? Feel free to comment with suggestions!
> Cheers,

I would say "please NO" cautiously.

As Petr said, kdump mostly works only if people configure it correctly.
That's because we try best to switch to kdump kernel from the fragile
panicked kernel immediately. When we try to add anthing before the switching,
please consider carefully and ask if that adding is mandatory, otherwise
switching into kdump kernel may fail. If the answer is yes, the adding
is needed and welcomed. Othewise, any unnecessary action, including any
"non-intrusive/non-risky" tasks, would be unwelcomed.

Surely, we don't oppose the "non-intrusive/non-risky" or completely
"intrusive/risky" action adding before kdump kernel switching, with a
conditional limitation. When we handle customers' kdump support, we
explicitly declare we only support normal and default kdump operation.
If any action which is done before switching into kdump kernel is specified,
e.g panic_notifier, panic_print, they need take care of their own kdump
failure.

Powered by blists - more mailing lists