linux-kernel - Re: [RFC v5 1/4] pstore/blk: new support logger for block devices

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190123181949.GC2792@darkstar.musicnaut.iki.fi>
Date:   Wed, 23 Jan 2019 20:19:49 +0200
From:   Aaro Koskinen <aaro.koskinen@....fi>
To:     liaoweixiong <liaoweixiong@...winnertech.com>,
        Kees Cook <keescook@...omium.org>
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 1/4] pstore/blk: new support logger for block devices

Hi,

On Sat, Jan 19, 2019 at 04:53:48PM +0800, liaoweixiong wrote:
> On 2019-01-18 08:12, Kees Cook wrote:
> >> MTD (drivers/mtd/mtdoops.c).
> > 
> > Would mtdoops get dropped in favor of pstore/blk, or do they not share
> > features?
> 
> We can show them what pstore/blk do. I think they will be interested in it.
> They should do a little work, including make a function for panic read,
> then they gain enhanced features, including present logs as a file,
> record multiple logs.

mtdoops has been in use over a decade and known working. What benefits
this new framework would offer? (BTW I don't see MTD as "block device".)

Why should there be a panic read? That adds complexity. This codes runs
on panic path, so it should be as simple and fast as possible.

Also compatibility has to be there. E.g. user upgrades an old system
(with mtdoops and related userspace) to a new kernel. Upgrade fails,
so the old software must be able to read the panic dumps properly to
tell the user why.

A.