linux-kernel - Re: [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]

Date:	Tue, 26 Jan 2016 10:46:34 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>
Cc:	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	David Vrabel <david.vrabel@...rix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Roger Pau Monné <roger.pau@...rix.com>,
	Juergen Gross <jgross@...e.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Borislav Petkov <bp@...e.de>,
	Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On Tue, Jan 26, 2016 at 10:34 AM, Luis R. Rodriguez <mcgrof@...e.com> wrote:
> On Mon, Jan 25, 2016 at 05:28:08PM -0500, Boris Ostrovsky wrote:
>> On 01/25/2016 04:21 PM, H. Peter Anvin wrote:
>> >On 01/25/16 13:12, Luis R. Rodriguez wrote:
>> >>>Perhaps, but someone would still have to set hardware_subarch. And
>> >>>it's hvmlite_bootparams() that does it.
>> >>No, Xen would do it as well, essentially all of hvmlite_bootparams() could be
>> >>done in Xen.
>> >>
>> >Or a stub code.
>>
>> This patch in fact is the stub for Xen HVMlite guests, after we are
>> done with it we jump to bare-metal startup code (i.e startup_32|64)
>
> Right the point is the stub need not be in Linux, I'll explain in the other
> thread where I provided more details on the different known approaches.
>

ISTM if the Xen ABI-specified entry point has a different convention
than the Linux native entry, then the stub should live in Linux.  It
would be just a couple if lines of code, right?

The issue that caused headaches in the past isn't that there's code
that's executed only on native, it's that there are whole big
functions that are executed only on native for no good reason and that
aren't clearly marked.

If we had native_start_kernel and xen_start_kernel, and they both
called very quickly in to common_start_kernel, it would be very clear
what's going on.

--Andy