linux-kernel - Re: [PATCH v8 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d18b961a-d115-8d12-8ee4-eb1a3466959c@redhat.com>
Date:   Fri, 7 Dec 2018 16:14:15 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Juergen Gross <jgross@...e.com>,
        Maran Wilson <maran.wilson@...cle.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, xen-devel@...ts.xenproject.org,
        kvm@...r.kernel.org
Cc:     tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
        boris.ostrovsky@...cle.com, jpoimboe@...hat.com,
        kirill.shutemov@...ux.intel.com, bp@...e.de,
        thomas.lendacky@....com, luto@...nel.org,
        dave.hansen@...ux.intel.com, roger.pau@...rix.com,
        rkrcmar@...hat.com, rdunlap@...radead.org
Subject: Re: [PATCH v8 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and
 CONFIG_XEN_PVH

On 07/12/18 14:58, Juergen Gross wrote:
> On 07/12/2018 14:52, Paolo Bonzini wrote:
>> On 07/12/18 14:50, Juergen Gross wrote:
>>> The PVH boot entry is in the same bzImage binary as the normal one.
>>> Its just another entry, similar to the Xen PV boot entry. So the binary
>>> arch/x86/boot/bzimage can be booted either on bare metal via grub2 or
>>> other boot-loaders, as Xen PV-guest, as Xen PVH-guest, or as KVM
>>> PVH-guest. So one build and one binary. The non-standard boot entries
>>> (PV- or PVH-node) are found via ELF-notes by the boot loader (qemu in
>>> case of KVM).
>>
>> But the bzImage is not an ELF binary, and it is compressed, isn't it?
>> /me is confused. :)
> 
> grub2 (and qemu, too) can decompress it. And the decompressed result
> "vmlinux" is an ELF-binary.

Aha - for KVM, the main advantage of PVH would be to skip the cost of
decompression, and that is what confused me (also we probably prefer not
having any decompression code running in QEMU, since that increases the
attack surface; there's no real disadvantage to using the existing
linuxboot code if we're given a bzImage).  So, at least for now, KVM
would go with the two-binaries/one-config approach.

Sorry for having you lecture me, it's much clearer now.  Thanks,

Paolo