linux-kernel - Re: [RFC v5 2/4] pstore/blk: add sample for pstore

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: <CAGXu5jKbqP=SaAGqUeP5yhObeLbWnDLXN1=tVQZAaOHxo+D5VQ@mail.gmail.com>
Date:   Thu, 17 Jan 2019 16:21:31 -0800
From:   Kees Cook <keescook@...omium.org>
To:     liaoweixiong <liaoweixiong@...winnertech.com>
Cc:     Anton Vorontsov <anton@...msg.org>,
        Colin Cross <ccross@...roid.com>,
        Tony Luck <tony.luck@...el.com>,
        Jonathan Corbet <corbet@....net>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "David S. Miller" <davem@...emloft.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Arnd Bergmann <arnd@...db.de>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v5 2/4] pstore/blk: add sample for pstore_blk

On Thu, Jan 17, 2019 at 4:15 PM Kees Cook <keescook@...omium.org> wrote:
>
> On Mon, Jan 7, 2019 at 4:01 AM liaoweixiong
> <liaoweixiong@...winnertech.com> wrote:
> >
> > It is a sample for pstore_blk, using general ram rather than block device.
> > According to pstore_blk, the data will be saved to ram buffer if not
> > register device path and apis for panic. So, it can only used to dump
> > Oops and some things will not reboot.
>
> I'm not sure I see the purpose of this implementation? Doesn't this
> just cause all the pstore machinery to skip any actions? i.e. without
> bzinfo->part_path, won't blkz_sample_write() just return -EINVAL, etc?

Say, instead of a no-op driver, can you build something like the how
ramoops processes module parameters, so that a person can define an
arbitrary device at boot time for blkoops? This also allows for easier
runtime testing too.

This all looks good, with some minor tweaks as mentioned. And on
closer review, yeah, it doesn't look like it shares much with ramoops.
:)

Thanks for sending this series; I look forward to the next version. :)

-Kees

-- 
Kees Cook