linux-kernel - Re: [Xen-devel] [PATCH v3 00/11] xen: Initial kexec/kdump implementation

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:	Wed, 02 Jan 2013 03:47:28 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andrew Cooper <andrew.cooper3@...rix.com>
Cc:	"x86\@kernel.org" <x86@...nel.org>,
	"konrad.wilk\@oracle.com" <konrad.wilk@...cle.com>,
	Daniel Kiper <daniel.kiper@...cle.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"kexec\@lists.infradead.org" <kexec@...ts.infradead.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	"virtualization\@lists.linux-foundation.org" 
	<virtualization@...ts.linux-foundation.org>,
	"mingo\@redhat.com" <mingo@...hat.com>,
	"jbeulich\@suse.com" <jbeulich@...e.com>,
	"maxim.uvarov\@oracle.com" <maxim.uvarov@...cle.com>,
	"tglx\@linutronix.de" <tglx@...utronix.de>,
	"xen-devel\@lists.xensource.com" <xen-devel@...ts.xensource.com>,
	"vgoyal\@redhat.com" <vgoyal@...hat.com>
Subject: Re: [Xen-devel] [PATCH v3 00/11] xen: Initial kexec/kdump implementation

Andrew Cooper <andrew.cooper3@...rix.com> writes:

> On 27/12/12 18:02, Eric W. Biederman wrote:
>> Andrew Cooper<andrew.cooper3@...rix.com>  writes:
>>
>>> On 27/12/2012 07:53, Eric W. Biederman wrote:
>>>> The syscall ABI still has the wrong semantics.
>>>>
>>>> Aka totally unmaintainable and umergeable.
>>>>
>>>> The concept of domU support is also strange.  What does domU support even mean, when the dom0 support is loading a kernel to pick up Xen when Xen falls over.
>>> There are two requirements pulling at this patch series, but I agree
>>> that we need to clarify them.
>> It probably make sense to split them apart a little even.
>>
>>
>
> Thinking about this split, there might be a way to simply it even more.
>
> /sbin/kexec can load the "Xen" crash kernel itself by issuing
> hypercalls using /dev/xen/privcmd.  This would remove the need for the
> dom0 kernel to distinguish between loading a crash kernel for itself
> and loading a kernel for Xen.
>
> Or is this just a silly idea complicating the matter?

At a first approximation it sounds reasonable.

If the Xen kexec actually copies the loaded kernel to somewhere internal
like the linux kexec that would be entirely reasonable.  If Xen has
other requirements on the dom0 case you might not be able to implement
the call without linux kernel support.

But if you can implement it all in terms of /dev/xen/privcmd go for it.

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/