linux-kernel - Re: [concept & "good taste" review] persistent store

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: <20101219091752.GA16150@liondog.tnic>
Date:	Sun, 19 Dec 2010 10:17:52 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Tony Luck <tony.luck@...il.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, tglx@...utronix.de, mingo@...e.hu,
	greg@...ah.com, akpm@...ux-foundation.org, ying.huang@...el.com,
	David Miller <davem@...emloft.net>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Kyungmin Park <kmpark@...radead.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [concept & "good taste" review] persistent store

On Sat, Dec 18, 2010 at 03:06:57PM -0800, Tony Luck wrote:
> > Doesn't that sound like the best of both worlds?
> 
> It sounds like an excellent heuristic for how the platform layer
> should manage the persistent store when space is tight. But
> I think that I can still keep my /dev/pstore filesystem as a
> presentation layer to make the bits available to the user in
> a device independent way.
> 
> Or perhaps the pstore layer can help with the implementation
> of the heuristic. It knows what items are in the pstore, so it
> could build & maintain the "ring" and pass the id of the least
> wanted item down to the platform layer whenever it wants to
> write a record ... with the platform layer giving a status to
> say whether it had to delete that item to make space for the
> new one?

Before we go and delve into priority-sorting the oopses in the pstore,
let me ask this: how big an actual persistent storage device are we
talking?

Because if it is big enough - for some value of 'big' - we could try to
never let it fill up. If want to save space we might even do something
crazy like compressing the oops info. In the rare event it fills up or
hits some 'almost-full' watermarks, we can kick some userspace daemon
to start writing the oopses to fs and clear the pstore. This all should
happen in the case where all you get is non-critical warnings and the
system is still alive.

However, in the critical cases, you get a single "stream" of oopses with
the first one being the most important one and then you panic. And in
most cases that stream is only a couple of oopses long. For that, the
pstore should be big enough to easily contain it.

  [ Btw, if we are able to write that stream to pstore before we panic,
 we solve all the problems we have with catching oopses with cameras,
 serial consoles, netconsoles, firewire and pen and paper! ]

In that case, when you restart the machine, the same daemon notices the
existence of the oopses and starts writing them to fs, notifies the
users and clears the pstore.

So, I think what we could do is keep our big enough pstore with enough
free space for a bunch of oopses in case we panic. In the remaining
cases, we write them out thus freeing some more space.

Hmmm..

-- 
Regards/Gruss,
    Boris.
--
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/