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 23:31:44 +0000
From:	Jamie Lokier <jamie@...reable.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Marco Stornelli <marco.stornelli@...il.com>,
	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

Andrew Morton wrote:
> > 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?

Me too, I think it's a great idea which sounds simpler to use than MTD-RAM.

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

It's good if there's an option to make the location not vary between
kernels, and be known to the bootloader.

Then you can debug kernels which always crash during boot, by either
booting into another kernel which works and looking at the oops, or by
a bootloader command to dump it.

That'd be fine if the kernel link scripts choose the address, as long
as it's consistent between different compiles and similar
configurations.  That'd be a bit simpler than the admin having to know
the memory map well enough to choose an address.

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