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]

Message-ID: <25d6db63-a57d-b15c-2d43-e96c506b4824@redhat.com>
Date:   Wed, 29 Nov 2017 15:44:14 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Roger Pau Monné <roger.pau@...rix.com>,
        Juergen Gross <jgross@...e.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, andrew.cooper3@...rix.com,
        kvm@...r.kernel.org
Subject: Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

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.

I actually like this patch, except that I'd get the e820 memory map from
fw_cfg (see the first part of
https://github.com/bonzini/qboot/blob/master/fw_cfg.c, and extract_e820
in https://github.com/bonzini/qboot/blob/master/main.c) instead of the
second module.

Thanks,

Paolo

> 
>> But then it won't be using the PVH entry point, and would just use the
>> native one?
>>
>> My understanding was that the PVH shim inside of Linux will prepare a
>> zero-page when booted using the PVH entry point, and then jump into
>> the native boot path.
> Right, but that's not what Juergen's second option is. IIUIC with that
> option Linux starts with zeropage already prepared. No shim in the kernel.