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: <20091118005337.GA19374@dvomlehn-lnx2.corp.sa.net>
Date:	Tue, 17 Nov 2009 19:53:37 -0500
From:	David VomLehn <dvomlehn@...co.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	dedekind1@...il.com, Marco Stornelli <marco.stornelli@...il.com>,
	Simon Kagstrom <simon.kagstrom@...insight.net>,
	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 Tue, Nov 17, 2009 at 04:28:22PM -0800, Eric W. Biederman wrote:
> David VomLehn <dvomlehn@...co.com> writes:
> 
> > On Tue, Nov 17, 2009 at 10:45:43AM -0500, Eric W. Biederman wrote:
> > ...
> >> Why not use the kdump hook?  If you handle a kernel panic that way
> >> you get enhanced reliability and full user space support.  All in a hook
> >> that is already present and already works.
...
> > 1. In what ways would this be better than, say, a panic_notifier?
> 
> A couple of ways. 
> 
> - You are doing the work in a known good kernel instead of the kernel
>   that just paniced for some unknown reason.
> - All of the control logic is in user space (not the kernel) so you can
>   potentially do something as simple as "date >> logfile" to get the
>   date.

I think I see better what you're suggesting--passing the info to a kdump
kernel and having it do whatever it wants. I don't think I want to do this,
but I haven't used any of the kexec() stuff, so I may be missing the point.
Some more context:

My application is an embedded one, and one of the big things I need to do
after a failure is to bring up a fully functional kernel ASAP. Once I have
that kernel, I process all of the crash data in user space concurrently with
running my main application. Because I'm embedded, I'm very limited in how
much crash data I can save over a reboot, how much I can store, and how
much I can send to a central collection point. This is good, since it doesn't
take up a lot of resources, but core dumps are out of the question.

As I understand kdump, I would also need to have a second kernel in memory
to do the kdump work. It wouldn't need to be as big is the kernel that
failed, but it would still require a significant amount of memory. On an
embedded system, the idle memory may be a luxury we can't afford.

I think this makes a kdump-based solution difficult, but if it can meet
my requirements, I'd much rather use it (I've been following kdump since
it's inception quite a few years ago, but it hasn't seemed a good match
for embedded Linux). Does this still sound like a good match?

> > 2. Where would you suggest tying in? (Particularly since not all architectures
> >    currently support kdump)
> 
> No changes are needed kernel side.  You just need an appropriate kernel and
> initrd for your purpose.

I think I must still be missing something. I have dynamic data that I want
to preserve as I reboot from a failed kernel to a fresh new kernel. By
the time the fresh kernel starts init, the dynamic data (IP addresses, MAC
addresses) has been re-written with new values. This is why I'm trying to
preserve, but I may be running without disk or flash. This patch doesn't
preserve the data, but it gets it into the kernel so that it can be
preserved. At present, I'm preserving the data in a panic_notifier function,
but I am not wedded to that. At present, the data will be copied to a
section of memory retained across boots, but I know others will want to
write to flash.

> All of the interesting architectures support kexec, and if an
> architecture doesn't it isn't hard to add.  The architecture specific
> part is very simple.  A pain to debug initially but very simple.

I use MIPS processors, and it looks like it is supported. So long as it's
stable, I'm happy to use it.

> Eric

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