linux-kernel - Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

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:   Wed, 29 Nov 2017 14:52:43 +0000
From:   Andrew Cooper <andrew.cooper3@...rix.com>
To:     Juergen Gross <jgross@...e.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Roger Pau Monné <roger.pau@...rix.com>
CC:     Maran Wilson <maran.wilson@...cle.com>, <tglx@...utronix.de>,
        <mingo@...hat.com>, <hpa@...or.com>, <x86@...nel.org>,
        <xen-devel@...ts.xenproject.org>, <linux-kernel@...r.kernel.org>,
        <rkrcmar@...hat.com>, <JBeulich@...e.com>, <kvm@...r.kernel.org>
Subject: Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 29/11/17 14:47, Juergen Gross wrote:
> On 29/11/17 15:44, Paolo Bonzini wrote:
>> On 29/11/2017 15:25, Boris Ostrovsky wrote:
>>>>>> zeropage is x86/Linux-specific so we'd need some sort of firmware (like
>>>>>> grub) between a hypervisor and Linux to convert hvm_start_info to
>>>>>> bootparams.
>>>>> qemu?
>>> I think KVM folks didn't want to do this. I can't find the thread but I
>>> believe it was somewhere during Clear Containers discussion. Paolo?
>> QEMU is the right place to parse the ELF file and save it in memory.
>> You would have to teach QEMU to find the Xen note in ELF-format kernels
>> (just like it looks for the multiboot header), and use a different
>> option ROM ("pvhboot.c" for example).
>>
>> However I don't like to bypass the BIOS; for -kernel, KVM starts the
>> guest with an option ROM (linuxboot-dma.c or multiboot.S in QEMU
>> sources) that takes care of boot.
>>
>> In either case, you would have a new option ROM.  It could either be
>> very simple and similar to multiboot.S, or it could be larger and do the
>> same task as xen-pvh.S and enlighten_pvh.c (then get the address of
>> startup_32 or startup_64 from FW_CFG_KERNEL_ENTRY and jump there).  The
>> ugly part is that the option ROM would have to know more details about
>> what it is going to boot, including for example whether it's 32-bit or
>> 64-bit, so I don't really think it is a good idea.
> As grub2 doesn't have to know, qemu shouldn't have to know either.

An underlying requirement for this boot protocol was to remove the
requirement for a priori knowledge of the eventual mode of the guest,
which plagues Xen PV guests.  (One way or another, we need to parse the
kernel which will end up running to work out how to build the domain for
it.)

32bit flat mode is easy to set up, sufficiently large for any reasonable
bootstrapping, and provides no restrictions to what the eventual guest
wants to do.

~Andrew