linux-kernel - Re: x86: kdump failure

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]

Date:	Fri, 18 Jan 2008 16:01:19 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Hiroshi Shimamoto <h-shimamoto@...jp.nec.com>, tglx@...utronix.de,
	hpa@...or.com, linux-kernel@...r.kernel.org
Subject: Re: x86: kdump failure

Oops, I overlooked the use of elf_core_copy_regs in kernel/kexec.c.  It
is certainly safe and fine to reintroduce the old macro.  Everything
removed in the "x86 user_regset cleanup" patch is purely removing code
and it doesn't hurt to have it back (it's just all unused except for this
kexec nit).

Unfortunately it really doesn't fit to have kexec call into the new
user_regset code that replaced this macro for user core dump purposes.
Those new interfaces are really purely for user-mode state, derived only
from task_struct (i.e. uses task_pt_regs), not from a struct pt_regs
pointer passed in.  (There is the minority case where it really is using
user-mode state.  That part could be done via the user_regset interface,
if that saved any trouble.)

Things like crash_fixup_ss_esp point to the poor fit of the code intended
for user core dumps with what kexec needs.  IMHO it would be cleaner for
kexec's arch interfaces to fill in elf_gregset_t directly, replacing some
of the places a struct pt_regs is passed around now.
crash_setup_regs already has to know the name of every register anyway.
A particular arch's definition can share code with its core dump or
user_regset code when that fits.

Thanks,
Roland
--
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/