Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966159AbcDMKPU (ORCPT ); Wed, 13 Apr 2016 06:15:20 -0400 Received: from mail-wm0-f49.google.com ([74.125.82.49]:38633 "EHLO mail-wm0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965432AbcDMKPS (ORCPT ); Wed, 13 Apr 2016 06:15:18 -0400 Date: Wed, 13 Apr 2016 11:15:15 +0100 From: Matt Fleming To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Cc: Andy Lutomirski , Juergen Gross , "Luis R. Rodriguez" , David Vrabel , Julien Grall , Stefano Stabellini , Andrew Cooper , Boris Ostrovsky , Charles Arndol , Jim Fehlig , Jan Beulich , Daniel Kiper , "H. Peter Anvin" , X86 ML , Gary Lin , Borislav Petkov , joeyli , Jeffrey Cheung , Michael Chang , =?utf-8?Q?Vojt=C4=9Bch_Pavl=C3=ADk?= , "linux-kernel@vger.kernel.org" , "xen-devel@lists.xenproject.org" , Linus Torvalds Subject: Re: HVMLite / PVHv2 - using x86 EFI boot entry Message-ID: <20160413101515.GJ2829@codeblueprint.co.uk> References: <20160406024027.GX1990@wotan.suse.de> <5704D978.1050101@citrix.com> <20160408204032.GR1990@wotan.suse.de> <570B3228.90400@suse.com> <20160413090202.bg2vfdl3iol7eedv@mac> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160413090202.bg2vfdl3iol7eedv@mac> User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3265 Lines: 67 On Wed, 13 Apr, at 11:02:02AM, Roger Pau Monn? wrote: > > With my FreeBSD committer hat: > > The FreeBSD kernel doesn't contain an EFI entry point, it just contains one > single entry point that's used for both legacy BIOS and EFI. Then the > FreeBSD loader is the one that contains the different entry points. I would > really like to avoid adding an EFI entry point and the PE header to the > FreeBSD kernel. The current trampoline in FreeBSD to tie the Xen entry point > into the native path contains 96 lines of assembly (half of them are > actually comments) and 66 lines of C. I think adding an EFI entry point is > going to add a lot more of code than this, and we would probably need > changes to the build system in order to assembly the PE header and the ELF > headers together. What does the boot flow look like for PVH2 on FreeBSD today? Presumably it doesn't have the same entry point that Boris proposed for Linux? Does it go, Hypervisor -> FreeBSD loader -> FreeBSD kernel? Or are you able to directly boot the kernel from the hypervisor and skip the middle part by having secondary entry point for Xen marked by the ELF note? > IMHO, if we want to boot PVH using EFI the right solution is to use OVMF (or > any other UEFI firmware) and port it so it's able to run as a PVH guest. I > guess it should even be possible to use it for Dom0, although I think this > is cumbersome. There are two levels of EFI boot entry features being discussed, 1. Make the OS kernel a PE/COFF executable 2. Provide some level of EFI service functionality You can adopt 1. without 2, i.e. without actually providing any EFI services at all, as long as the Xen hypervisor grows a PE/COFF loader (since EFI firmware has to provide you one, for EFI platforms you could use the LoadImage() service in the firmware, but for BIOS platforms you'd need your own in Xen). On Linux, this has the advantage of deferring the decompression of the bzImage (x86 Linux kernel file format) to the stub on the front of the bzImage. And while I realise that the toolstack already has support for decompressing bzImages, given what Andrew has said about reducing attack surface, having the guest perform the decompression should be a win. Of course, this is offset somewhat by the fact that you need to audit the PE/COFF loader ;) But decompression in general is notoriously vulnerable to security issues. Using the in-kernel decompressor is how most (all?) Linux boot loaders work today, so there's the added benefit of reducing the differences between booting on Xen and booting bare metal. For example, you'd probably be able to use CONFIG_RANDOMIZE_BASE (ASLR for kernel image) for Xen if you use the kernel's decompressor. Xen would also get future features in this area for free, and there is a tendency to push boot features into the early stub. For 1. we'd basically be using the PE/COFF file format with the EFI ABI as an OS agnostic boot protocol, but not as a full firmware runtime environment. 2. is also interesting, though I think less so than 1. I agree that making OVMF work as a PVH guest is probably the right way to go, even for Dom0, not least because you'd have a much cleaner/less buggy implementation than what we see in the real world ;)