linux-kernel - Re: [PATCH, RFC] panic-note: Annotation from user space for panics

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: <20091113091031.3f6d4bba@marrow.netinsight.se>
Date:	Fri, 13 Nov 2009 09:10:31 +0100
From:	Simon Kagstrom <simon.kagstrom@...insight.net>
To:	David VomLehn <dvomlehn@...co.com>
Cc:	Marco Stornelli <marco.stornelli@...il.com>,
	linux-embedded@...r.kernel.org, akpm@...ux-foundation.org,
	dwm2@...radead.org, linux-kernel@...r.kernel.org, mpm@...enic.com,
	paul.gortmaker@...driver.com
Subject: Re: [PATCH, RFC] panic-note: Annotation from user space for panics

On Thu, 12 Nov 2009 16:56:49 -0500
David VomLehn <dvomlehn@...co.com> wrote:

> Good question. Some more detail on our application might help. In some
> situations, we may have no disk and only enough flash for the bootloader.
> The kernel is downloaded over the network. When we get to user space, we
> initialize a number of things dynamically. For example, we dynamically
> compute some MAC address, and most of the IP addresses are obtained with
> DHCP. This are very useful to have for panic analysis.
> 
> Since there is neither flash nor disk, user space has no place to store
> this information, should the kernel panic. When we come back up, we will get
> different MAC and IP addresses. Storing them in memory is our only hope.
> 
> Fortunately, there is a section of RAM that the bootloader promises not
> to overwrite. On a panic, we capture the messages written on the console
> and store them in the protected area. If the information from the
> /proc file is written as part of the panic, we will capture it, too.

Can't you solve this completely from userspace using phram and mtdoops
instead? I.e., setup two phram areas

	modprobe phram 4K@...rt-of-your-area,4K@...rt-of-your-area+4K    # Can't remember the exact syntax!

you'll then get /dev/mtdX and /dev/mtdX+1 for these two. You can then do

	modprobe mtdoops mtddev=/dev/mtdX+1 dump_oops=0

to load mtdoops to catch the panic in the second area, and just write
your userspace messages to /dev/mtdX.


One thing probably have to be fixed though: I don't think phram has a
panic_write, which will be needed by mtdoops to catch the panic - this
should be trivial to add though since it's plain RAM.

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