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:   Thu, 30 Nov 2017 10:23:17 -0800
From:   Maran Wilson <maran.wilson@...cle.com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Roger Pau Monné <roger.pau@...rix.com>,
        Juergen Gross <jgross@...e.com>
Cc:     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 11/29/2017 6:44 AM, Paolo Bonzini wrote:
> 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
> inhttps://github.com/bonzini/qboot/blob/master/main.c) instead of the
> second module.

Hi Paolo,

I want to make sure I understand exactly what you are suggesting...

Are you saying the Linux PVH entry code (such as init_pvh_bootparams()) 
should use the fw_cfg interface to read the e820 memory map data and put 
it into the zeropage? Basically, keeping the patch very much like it 
already is, just extracting the e820 data via the fw_cfg interface 
instead of from the second module of start_info struct?

If that is the case, I guess I'm a bit hesitant to throw the QEMU 
specific fw_cfg interface into the mix on the Linux PVH side when the 
existing PVH ABI already seems to contain an interface for passing 
modules/blobs to the guest. But if you feel there is a compelling reason 
to use the fw_cfg interface here, I'm happy to explore that approach 
further.

Thanks,
-Maran

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ