linux-kernel - Re: [PATCH v1 0/3] allow ramoops to collect all kmesg

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: <CA+CK2bBDzbXdH23aDxqGzMoxPppNcVmitrYJ00tJqympMBVJOg@mail.gmail.com>
Date:   Mon, 4 May 2020 14:47:45 -0400
From:   Pavel Tatashin <pasha.tatashin@...een.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     James Morris <jmorris@...ei.org>, Sasha Levin <sashal@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>, anton@...msg.org,
        ccross@...roid.com, Tony Luck <tony.luck@...el.com>,
        robh+dt@...nel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v1 0/3] allow ramoops to collect all kmesg_dump events

> > # reboot -f
> >
> > After VM is back:
> >
> > # mount -t pstore pstore /mnt
> > # head /mnt/dmesg-ramoops-0
> > Restart#1 Part1
>
> Is there a reason that using ramoops.console_size isn't sufficient for
> this?

Unfortunately, the console option is not working for us (Microsoft),
we have an embedded device with a serial console, and the baud rate
reduces the reboot performance, so we must keep the console quiet. We
also want to be able collect full shutdown logs from the field that
are collected during kexec based updates.

>
> I'm not strictly opposed to making these changes, but traditionally the
> granularity of dmesg output has been pretty easily "all or crashes"
> instead of a range within.

As of now, ramoops  allows collecting dmesg only for oops and panic,
but not for all types of events.

Thank you,
Pasha

On Mon, May 4, 2020 at 2:14 PM Kees Cook <keescook@...omium.org> wrote:
>
> On Sat, May 02, 2020 at 10:35:52AM -0400, Pavel Tatashin wrote:
> > Currently, ramoops is capable to collect dmesg buffer only during
> > panic and oops events. However, it is desirable for shutdown performance
> > analysis reasons to optionally allow collecting dmesg buffers during other
> > events as well: reboot, kexec, emergency reboot etc.
> >
> > How to quickly test:
> >
> > virtme-run --mods=auto --kdir --mods=auto --kdir . \
> >       -a memmap=1G$8G -a ramoops.mem_address=0x200000000 \
> >       -a ramoops.mem_size=0x100000 -a ramoops.record_size=32768 \
> >       -a ramoops.dump_all=1 -a quiet --qemu-opts -m 8G
> > ..
> > # reboot -f
> >
> > After VM is back:
> >
> > # mount -t pstore pstore /mnt
> > # head /mnt/dmesg-ramoops-0
> > Restart#1 Part1
>
> Is there a reason that using ramoops.console_size isn't sufficient for
> this?
>
> I'm not strictly opposed to making these changes, but traditionally the
> granularity of dmesg output has been pretty easily "all or crashes"
> instead of a range within.
>
> --
> Kees Cook