linux-kernel - Re: EFI and multiboot2 devlopment work for Xen

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: <526F7FC402000078000FD7BA@nat28.tlf.novell.com>
Date:	Tue, 29 Oct 2013 08:28:36 +0000
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Vladimir 'φ-coder/phcoder' Serbinenko" 
	<phcoder@...il.com>
Cc:	<ian.campbell@...rix.com>, <ross.philipson@...rix.com>,
	<stefano.stabellini@...citrix.com>,
	"The development of GNU GRUB" <grub-devel@....org>,
	<david.woodhouse@...el.com>, <richard.l.maliszewski@...el.com>,
	<xen-devel@...ts.xen.org>, <boris.ostrovsky@...cle.com>,
	"Daniel Kiper" <daniel.kiper@...cle.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@...cle.com>,
	<seth.goldberg@...cle.com>, <pjones@...hat.com>,
	<linux-kernel@...r.kernel.org>, <keir@....org>
Subject: Re: EFI and multiboot2 devlopment work for Xen

>>> On 28.10.13 at 19:01, Vladimir 'f-coder/phcoder' Serbinenko<phcoder@...il.com> wrote:
>>>> Will a multiboot2 tag with whole EFI memory map solve your problem?
>>> I added such a tag in documentation and wrote a patch for it (attached).
>>> Awaiting for someone to test it to commit
>> 
>> Great! I think from Xen perspective we first need to have Xen be able
>> to understand multiboot2 - that is something Daniel had been working on.
>> I will let Daniel talk more about it.
>> 
>> Seth, would you have any time to test the patch against Solaris to
>> make sure it works?
>> 
> I've committed that patch. BTW do you want protected mode or long mode
> entry point for x86_64 variant? Currently it's protected mode but I
> planned to add long mode possibility but it wasn't a priority.

32-bit protected mode is obviously the more consistent model
with multiboot1. But since we'll want to avoid switching back to
real mode when booted from UEFI, long mode would certainly
be an option too (just that the code paths would need to
diverge more).

Jan

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