linux-kernel - Re: [RFC] firmware coredump: add new firmware coredump class

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, 03 Sep 2014 21:21:21 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Seth Forshee <seth.forshee@...onical.com>,
	linux-kernel@...r.kernel.org,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Emmanuel Grumbach <emmanuel.grumbach@...el.com>,
	luca@...lho.fi, kvalo@...rom.com
Subject: Re: [RFC] firmware coredump: add new firmware coredump class

On Wed, 2014-09-03 at 12:15 -0700, Greg Kroah-Hartman wrote:
> On Wed, Sep 03, 2014 at 09:00:42PM +0200, Johannes Berg wrote:
> > On Wed, 2014-09-03 at 09:38 -0500, Seth Forshee wrote:
> > 
> > > Overall I think this looks pretty sensible. The thing that worries me
> > > though is firmware which might crash repeatedly in a short period of
> > > time, resulting in a proliferation of coredumps and eating up all
> > > available RAM. How about a limit of one active coredump per device or
> > > something similar?
> > 
> > Oh, right, I completely forgot about that. Not sure what context I can
> > iterate the class device list, but worst case I have to add another
> > list.
> 
> Before you add another device, walk the list of all devices of the class
> to see if there is already a device with the same parent.  If so, delete
> that one and then continue and add the one you wanted to create.

Or throw away the new data, yeah. The "context" part was just that I was
aiming to make this function callable say without being able to sleep
(hence also the gfp_t argument) but I don't know for sure I can iterate
the class device list that way. I can look it up though - no need for
anyone else to answer that question :)

> > We likely want to store the first dump then, I suppose?
> 
> Or the last one?  I don't know...

It might even have to be device-specific policy? But in general I'd
think that the first would make more sense because mostly we'd try to
recover from the issue, but if that results in another issue that's
usually not all that helpful to know about.

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/