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]

Date:	Tue, 17 Nov 2009 16:28:22 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	David VomLehn <dvomlehn@...co.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

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.
>
> I'm a big fan of avoiding reinvention of the wheel--if I can use something
> already present, I will. However, I'm not clear about how much of the problem
> I'm addressing will be solved by using a kdump hook. If I understand
> correctly, you'd still need a pseudo-file somewhere to actually get the data
> from user space to kernel space. *Then* you could use a kdump hook to
> transfer the data to flash or some memory area that will be retained across
> boots. Is this the approach to which you were referring? If so, I have a
> couple more questions:
>
> 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.

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

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.

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/