linux-kernel - Re: [PATCH 7/9] xen/x86: hook up 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]

Date:   Thu, 23 Sep 2021 17:19:36 +0200
From:   Jan Beulich <jbeulich@...e.com>
To:     Juergen Gross <jgross@...e.com>
Cc:     Stefano Stabellini <sstabellini@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>
Subject: Re: [PATCH 7/9] xen/x86: hook up xen_banner() also for PVH

On 23.09.2021 17:15, Juergen Gross wrote:
> On 23.09.21 17:10, Jan Beulich wrote:
>> On 23.09.2021 16:59, Juergen Gross wrote:
>>> On 07.09.21 12:11, Jan Beulich wrote:
>>>> This was effectively lost while dropping PVHv1 code. Move the function
>>>> and arrange for it to be called the same way as done in PV mode. Clearly
>>>> this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad
>>>> check that was recently removed, as that's a PV-only feature.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@...e.com>
>>>>
>>>> --- a/arch/x86/xen/enlighten.c
>>>> +++ b/arch/x86/xen/enlighten.c
>>>> @@ -261,6 +261,18 @@ int xen_vcpu_setup(int cpu)
>>>>    	return ((per_cpu(xen_vcpu, cpu) == NULL) ? -ENODEV : 0);
>>>>    }
>>>>    
>>>> +void __init xen_banner(void)
>>>> +{
>>>> +	unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
>>>> +	struct xen_extraversion extra;
>>>
>>> Please add a blank line here.
>>
>> Oops.
>>
>>>> +	HYPERVISOR_xen_version(XENVER_extraversion, &extra);
>>>> +
>>>> +	pr_info("Booting paravirtualized kernel on %s\n", pv_info.name);
>>>
>>> Is this correct? I don't think the kernel needs to be paravirtualized
>>> with PVH (at least not to the same extend as for PV).
>>
>> What else do you suggest the message to say? Simply drop
>> "paravirtualized"? To some extent it is applicable imo, further
>> qualified by pv_info.name. And that's how it apparently was with
>> PVHv1.
> 
> The string could be selected depending on CONFIG_XEN_PV.

Hmm, now I'm confused: Doesn't this setting control whether the kernel
can run in PV mode? If so, that functionality being present should have
no effect on the functionality of the kernel when running in PVH mode.
So what you suggest would end up in misleading information imo.

Jan