linux-kernel - Re: [PATCH v2] char drivers: Ram oops/panic logger

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:	Fri, 12 Mar 2010 14:48:54 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Marco Stornelli <marco.stornelli@...il.com>
Cc:	Yuasa Yoichi <yuasa@...ux-mips.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Linux Embedded <linux-embedded@...r.kernel.org>
Subject: Re: [PATCH v2] char drivers: Ram oops/panic logger

On Wed, 10 Mar 2010 13:15:25 +0100
Marco Stornelli <marco.stornelli@...il.com> wrote:

> 2010/3/10 Yuasa Yoichi <yuasa@...ux-mips.org>:
> > 2010/3/10 Marco Stornelli <marco.stornelli@...il.com>:
> >> 2010/3/10 Yuasa Yoichi <yuasa@...ux-mips.org>:
> >>> Hi,
> >>>
> >>> 2010/3/10 Marco Stornelli <marco.stornelli@...il.com>:
> >>>> Ramoops, like mtdoops, can log oops/panic information but in RAM.
> >>>
> >>> What is different from mtdoops + mtd-ram?
> >>>
> >>> Yoichi
> >>>
> >>
> >> It can be used in a very easy way with persistent RAM for systems
> >> without flash support. For this systems, with this driver, it's no
> >> more needed add to the kernel the mtd subsystem with advantage in
> >> footprint as I said in the description.
> >
> > right.
> > But,
> >
> >> In addition, you can save
> >> flash space and store this information only in RAM. I think it's very
> >> useful for embedded systems.
> >
> > CONFIG_MTD_RAM uses only RAM.
> > I think there's no big difference about this point.
> >
> 
> I meant with the "classic" use of mtdoops, therefore with a flash
> partition without use MTD_RAM. Using MTD_RAM, it's more or less the
> same thing, with the exception of "where" you want deploy the log. For
> example: if in your system you have got a nvram you can use it without
> problem, you need to specify the address of the nvram to the module.
> Very simple. I  think it's a small driver but very useful, feedback
> from other embedded guys are welcome.

Seems sensible to me.  If you have a machine whose memory is persistent
across reboots then you reserve an arbitrary 4k hunk of memory for
collecting oops traces, yes?

What tools are used for displaying that memory on the next boot?  How
do those tools distinguish between "valid oops trace" and "garbage
because it was just powered on"?  A magic signature?

Should the kernel provide the 4k of memory rather than (or in addition
to) requiring that the system administrator reserve it and tell the
kernel about it?  That'd be a matter of creating a linker section which
isn't cleared out by the startup code.

--
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/