linux-kernel - Re: [PATCH 6/9] xen/x86: generalize preferred console model from PV to PVH Dom0

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, 23 Sep 2021 16:54:59 +0200
From:   Juergen Gross <jgross@...e.com>
To:     Jan Beulich <jbeulich@...e.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>
Cc:     Stefano Stabellini <sstabellini@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>
Subject: Re: [PATCH 6/9] xen/x86: generalize preferred console model from PV
 to PVH Dom0

On 07.09.21 12:10, Jan Beulich wrote:
> Without announcing hvc0 as preferred it won't get used as long as tty0
> gets registered earlier. This is particularly problematic with there not
> being any screen output for PVH Dom0 when the screen is in graphics
> mode, as the necessary information doesn't get conveyed yet from the
> hypervisor.
> 
> Follow PV's model, but be conservative and do this for Dom0 only for
> now.
> 
> Signed-off-by: Jan Beulich <jbeulich@...e.com>

Reviewed-by: Juergen Gross <jgross@...e.com>

> ---
> Prior to 418492ba40b2 ("x86/virt/xen: Use guest_late_init to detect Xen
> PVH guest") x86_init.oem.arch_setup was already used by PVH, so I assume
> the use of this hook is acceptable here.

Yes, I think so.

> Seeing that change, I wonder in how far setting xen_pvh to true only in
> xen_hvm_guest_late_init() can really work: This hook, as its name says,
> gets called pretty late; any decision taken earlier might have been
> wrong. One such wrong decision is what gets added here - preferred
> consoles won't be registered when taking that path. While adding a 2nd
> call there might work, aiui they would better be registered prior to
> parse_early_param(), i.e. before "earlyprintk=" gets evaluated.
> 
> I also consider tying "detecting" PVH mode to the no-VGA and no-CMOS-RTC
> FADT flags as problematic looking forward: There may conceivably be
> "legacy free" HVM guests down the road, yet they shouldn't be mistaken
> for being PVH. Most of the XEN_X86_EMU_* controlled functionality would
> seem unsuitable for the same reason; presence/absence of
> XENFEAT_hvm_pirqs (tied to XEN_X86_EMU_USE_PIRQ) might be sufficiently
> reliable an indicator. Question there is whether the separation
> introduced by Xen commit b96b50004804 ("x86: remove XENFEAT_hvm_pirqs
> for PVHv2 guests") came early enough in the process of enabling PVHv2.

Yes, it did. The boot path not using the PVH specific entry point was
enabled with Xen 4.11, while commit b96b50004804 was in 4.9.


Juergen

Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3092 bytes)

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (496 bytes)