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:	Mon, 7 Jan 2013 10:46:45 +0000
From:	Andrew Cooper <andrew.cooper3@...rix.com>
To:	Ian Campbell <Ian.Campbell@...rix.com>
CC:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Daniel Kiper <daniel.kiper@...cle.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"virtualization@...ts.linux-foundation.org" 
	<virtualization@...ts.linux-foundation.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Jan Beulich <JBeulich@...e.com>,
	"maxim.uvarov@...cle.com" <maxim.uvarov@...cle.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"vgoyal@...hat.com" <vgoyal@...hat.com>
Subject: Re: [Xen-devel] [PATCH v3 00/11] xen: Initial kexec/kdump implementation

On 07/01/13 10:25, Ian Campbell wrote:
> On Fri, 2013-01-04 at 19:11 +0000, Konrad Rzeszutek Wilk wrote:
>> On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
>>> Because current KEXEC_CMD_kexec_load does not load kernel
>>> image and other things into Xen memory. It means that it
>>> should live somewhere in dom0 Linux kernel memory.
>> We could have a very simple hypercall which would have:
>>
>> struct fancy_new_hypercall {
>> 	xen_pfn_t payload; // IN
> This would have to be XEN_GUEST_HANDLE(something) since userspace cannot
> figure out what pfns back its memory. In any case since the hypervisor
> is going to want to copy the data into the crashkernel space a virtual
> address is convenient to have.
>
>> 	ssize_t len; // IN
>> #define DATA (1<<1)
>> #define DATA_EOF (1<<2)
>> #define DATA_KERNEL (1<<3)
>> #define DATA_RAMDISK (1<<4)
>> 	unsigned int flags; // IN
>> 	unsigned int status; // OUT
>> };
>>
>> which would in a loop just iterate over the payloads and
>> let the hypervisor stick it in the crashkernel space.
>>
>> This is all hand-waving of course. There probably would be a need
>> to figure out how much space you have in the reserved Xen's
>> 'crashkernel' memory region too.
> This is probably a mad idea but it's Monday morning and I'm sleep
> deprived so I'll throw it out there...
>
> What about adding DOMID_KEXEC (similar DOMID_IO etc)? This would allow
> dom0 to map the kexec memory space with the usual privcmd mmap
> hypercalls and build things in it directly.
>
> OK, I suspect this might not be practical for a variety of reasons (lack
> of a p2m for such domains so no way to find out the list of mfns, dom0
> userspace simply doesn't have sufficient context to write sensible
> things here, etc) but maybe someone has a better head on today...
>
> Ian.
>

Given that /sbin/kexec creates a binary blob in memory, surely the most 
simple thing is to get it to suitably mlock() the region and give a list 
of VAs to the hypervisor.

This way, Xen can properly take care of what it does with information 
and where.  For example, at the moment, allowing dom0 to choose where 
gets overwritten in the Xen crash area is a recipe for disaster if a 
crash occurs midway through loading/reloading the crash kernel.

~Andrew

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