linux-kernel - Re: efi-pstore: Crash logs not written

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] [day] [month] [year] [list]

Message-ID: <201909241857.9BBBA707D@keescook>
Date:   Tue, 24 Sep 2019 19:01:43 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Paul Menzel <pmenzel@...gen.mpg.de>
Cc:     Anton Vorontsov <anton@...msg.org>,
        Colin Cross <ccross@...roid.com>,
        Tony Luck <tony.luck@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: efi-pstore: Crash logs not written

On Thu, Sep 12, 2019 at 02:51:53PM +0200, Paul Menzel wrote:
> On a Dell OptiPlex 5040 with Linux 5.3-rc8, I’ll try to get
> efi-pstore working.
> 
> ```
> $ lsmod | grep efi
> efi_pstore             16384  0
> pstore                 28672  1 efi_pstore
> efivarfs               16384  1
> $ dmesg | grep pstore
> [ 2569.826541] pstore: Using crash dump compression: deflate
> [ 2569.826542] pstore: Registered efi as persistent store backend
> ```
> 
> Triggering a crash with `echo c | sudo tee /proc/sysrq-trigger`,
> there is nothing in `/sys/fs/pstore` after the reboot.
> 
> Please note, that there is also a crash kernel configured, so
> there are actually to reboots, but that should not conflict,
> right?

As long as the crash kernel doesn't delete all the EFI stored variables,
I would expect them to survive.

> Hints on how to debug that would be appreciated. Please find the
> Linux messages attached.

Things seem correct, though I've only done EFI testing under QEMU...
do other things, like BUG (rather than a full panic()) get recorded?
(Maybe try with the lkdtm module?) There was another recent issue with
the "c" sysrq[1] but that seemed to be Xen-specific.

[1] https://lore.kernel.org/lkml/be41da82-3adc-4ab1-e4f9-5fdf11ac4b08@oracle.com/

-- 
Kees Cook