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] [day] [month] [year] [list]

Message-ID: <m1iqd77l6r.fsf@fess.ebiederm.org>
Date:	Wed, 18 Nov 2009 10:16:28 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Tim Bird <tim.bird@...sony.com>
Cc:	Matt Mackall <mpm@...enic.com>, David VomLehn <dvomlehn@...co.com>,
	"dedekind1\@gmail.com" <dedekind1@...il.com>,
	Marco Stornelli <marco.stornelli@...il.com>,
	Simon Kagstrom <simon.kagstrom@...insight.net>,
	"linux-embedded\@vger.kernel.org" <linux-embedded@...r.kernel.org>,
	"akpm\@linux-foundation.org" <akpm@...ux-foundation.org>,
	"dwm2\@infradead.org" <dwm2@...radead.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	"paul.gortmaker\@windriver.com" <paul.gortmaker@...driver.com>
Subject: Re: [PATCH, RFC] panic-note: Annotation from user space for panics

Tim Bird <tim.bird@...sony.com> writes:

> Eric W. Biederman wrote:
>> Matt Mackall <mpm@...enic.com> writes:
>> 
>>> As much as I like kexec, it loses on memory footprint by about 100x.
>>> It's not appropriate for all use cases, especially things like
>>> consumer-grade wireless access points and phones.
>> 
>> In general I agree.  The cost of a second kernel and initrd can be
>> prohibitive in the smallest systems, and if you do a crash capture
>> with using a standalone app that is reinventing the wheel.
>> 
>> That said.  I can happily run kdump with only 16M-20M reserved.
>> So on many systems the cost is affordable.
>
> Understood.  On some of my systems, the memory budget for the
> entire system is 10M.  On most systems I work with, it is a
> struggle to reserve even 64K for this feature.

crash_kexec is really a glorified jump.  It is possible to do a lot in
64K with a standalone application.  If reliable capture of kernel
crashes is desirable to an embedded NAND device I expect a semi-general
purpose dedicated application for capturing at least dmesg from the
crashed kernel and write it to a file on a NAND filesystem could be
worth someones time.

On general purpose hardware we use a kernel and an initrd simply to
reduce the development work of supporting everything and the kitchen
sink.  My impression is that embedded systems can afford a little more
setup time, and a custom compilation, and that the hardware you would like
to store things too is much more common.

Eric

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