linux-kernel - Re: [Xen-devel] [PATCH v2 1/2] xen/pvh: set xen_domain_type to HVM in xen_pvh

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: <20190423145601.7qwu63sz2ycg5ywj@Air-de-Roger>
Date:   Tue, 23 Apr 2019 16:56:01 +0200
From:   Roger Pau Monné <roger.pau@...rix.com>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.com>
CC:     <linux-kernel@...r.kernel.org>, Juergen Gross <jgross@...e.com>,
        <xen-devel@...ts.xenproject.org>
Subject: Re: [Xen-devel] [PATCH v2 1/2] xen/pvh: set xen_domain_type to HVM
 in xen_pvh_init

On Tue, Apr 23, 2019 at 09:37:51AM -0400, Boris Ostrovsky wrote:
> On 4/23/19 9:04 AM, Roger Pau Monne wrote:
> > Or else xen_domain() returns false despite xen_pvh being set.
> 
> Is this new xen_domain() invocation somewhere in EFI initialization that
> you add in the second patch?

Yes, there's a xen_initial_domain() call in xen_efi_probe() which
would return false without this fix.

> Asking because I am trying to figure out whether this needs to go to
> stable tree.

I'm not aware of this being an issue without the EFI code that I add
in patch 2, xen_domain_type would get set slightly later in the boot
process.

I guess both patches should be backported to 4.19 since that's the
only LTS release that has PVH dom0 support IIRC, and it would be good
to get this fixed.

Thanks, Roger.