linux-kernel - Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

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]

Message-ID: <56A2C99A.2050701@citrix.com>
Date:	Sat, 23 Jan 2016 00:30:18 +0000
From:	Andrew Cooper <andrew.cooper3@...rix.com>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>
Cc:	Juergen Gross <jgross@...e.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	linux-kernel@...r.kernel.org,
	Andy Lutomirski <luto@...capital.net>, david.vrabel@...rix.com,
	hpa@...or.com, xen-devel@...ts.xenproject.org,
	Borislav Petkov <bp@...e.de>, roger.pau@...rix.com
Subject: Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 22/01/2016 23:32, Luis R. Rodriguez wrote:
> On Fri, Jan 22, 2016 at 04:35:50PM -0500, Boris Ostrovsky wrote:
>> +	/*
>> +	 * See Documentation/x86/boot.txt.
>> +	 *
>> +	 * Version 2.12 supports Xen entry point but we will use default x86/PC
>> +	 * environment (i.e. hardware_subarch 0).
>> +	 */
>> +	xen_hvmlite_boot_params.hdr.version = 0x212;
>> +	xen_hvmlite_boot_params.hdr.type_of_loader = 9; /* Xen loader */
>> +}
> I realize PV got away with setting up boot_params on C code but best
> ask now that this new code is being introduced: why can't we just have
> the Xen hypervisor fill this in? It'd save us all this code.

I agree that this looks to be a mess.  Having said that, the DMLite boot
protocol is OS agnostic, and will be staying that way.

It happens to look suspiciously like multiboot; a flat 32bit protected
mode entry (at a location chosen in an ELF note), with %ebx pointing to
an in-ram structure containing things like a command line and module list.

I would have though the correct way to do direct Linux support would be
to have a very small init stub which constructs an appropriate zero
page, and lets the native entry point get on with things.

This covers the usecase where people wish to boot a specific Linux
kernel straight out of the dom0 filesystem.

For the alternative usecase of general OS support, dom0 would boot
something such as grub2 as the DMLite "kernel", at which point all
stooging around in the guests filesystem is done from guest context,
rather than control context (mitigating a substantial attack surface).

~Andrew