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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56A6A7C6.8060906@oracle.com>
Date:	Mon, 25 Jan 2016 17:55:02 -0500
From:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>,
	Andrew Cooper <andrew.cooper3@...rix.com>
Cc:	Roger Pau Monné <roger.pau@...rix.com>,
	Juergen Gross <jgross@...e.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	David Vrabel <david.vrabel@...rix.com>,
	"H. Peter Anvin" <hpa@...or.com>, xen-devel@...ts.xenproject.org,
	Borislav Petkov <bp@...e.de>
Subject: Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 01/25/2016 05:19 PM, Luis R. Rodriguez wrote:
> On Sat, Jan 23, 2016 at 02:49:36PM +0000, Andrew Cooper wrote:
>
>
>> it causes inappropriate linkage between the
>> toolstack and the version of Linux wishing to be booted.
> There are ways to do it in such a way that it does not create dependency issues
> on Linux specific code.
>
>
> 0) The Xen way and EFI way
>
> A generic data structure is passed to the entry point on the kernel to
> load the kernel. The kernel in turn must parse this generic specific struct
> and interprets it and translate it to the kernel specific values.
>
> 1) The qemu way:
>
> One way is to simply not refer to the boot_params data structures but IMHO that
> produces really ugly code. The qemu folks did it this way, so qemu does not use
> arch/x86/include/uapi/asm/bootparam.h in any way, instead it uses offsets from
> a char *header. Refer to load_linux() in hw/i386/pc.c, for instance:
>
> header[0x211] |= 0x80;  /* CAN_USE_HEAP */
>
> 2) The grub way:
>
> Another way, which grub uses, is to define their own data structures based
> on arch/x86/include/uapi/asm/bootparam.h, with their own data types, and refer
> to them in code, for instance refer to grub_cmd_linux() on the grub file
> grub-core/loader/i386/pc/linux.c and its copy definition of the header definition
> in include/grub/i386/linux.h.
>
> lh.loadflags |= GRUB_LINUX_FLAG_CAN_USE_HEAP;
>
> The way lguest does it in the lguest launcher is IMHO the cleanest of course,
> but it includes asm/bootparam.h and uses that in code:
>
> /* Boot protocol version: 2.07 supports the fields for lguest. */
> boot->hdr.version = 0x207;
>
> But that does mean copying over or using the bootparam.h file and using
> linux data types.
>
> 3) Merge of xen way and using subarch_data
>
> Only set the subarch and subarch_data pointer, and have the kernel then
> read the generic data structure and parse it as it used to, the benefit
> is sharing a common entry point.
>
> No one uses this yet. But I think its a reasonable compromise.
>
> Perhaps there are other ways as well.
>
>>> If true, then by no means, no matter how hard we try, and no matter
>>> what we do on the Linux front to help clean things up will we be able
>>> to have a unified bare metal / Xen entry. I'm noting it could be
>>> possible though provided we do just set the zero page, the subarch to
>>> Xen and subarch_data to the Xen custom data structure.
>> All you need is a very small stub which starts per the DMLite ABI, sets
>> up an appropriate zero_page, and jumps to the native entrypoint.
> Right.


I am trying to understand what your objection is to what is proposed in 
this patch. It is the size of the stub? If yes -- what would you like to 
leave out to be done later?


-boris

>
>> However, this stub belongs in Linux, not in the Xen toolstack.  That
>> way, when the Linux boot protocol is modified, both sides can be updated
>> accordingly.
> Makes sense the different entry points just seems best avoided if possible.
>
>    Luis