linux-kernel - Re: [PATCH RFC v1 07/18] x86/hyperv: extract partition ID from Microsoft Hypervisor if necessary

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: <20201027121944.s3r7l24gf4ayjobu@liuwe-devbox-debian-v2>
Date:   Tue, 27 Oct 2020 12:19:44 +0000
From:   Wei Liu <wei.liu@...nel.org>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     Wei Liu <wei.liu@...nel.org>,
        Linux on Hyper-V List <linux-hyperv@...r.kernel.org>,
        virtualization@...ts.linux-foundation.org,
        Linux Kernel List <linux-kernel@...r.kernel.org>,
        Michael Kelley <mikelley@...rosoft.com>,
        Vineeth Pillai <viremana@...ux.microsoft.com>,
        Sunil Muthuswamy <sunilmut@...rosoft.com>,
        Nuno Das Neves <nudasnev@...rosoft.com>,
        Lillian Grassin-Drake <ligrassi@...rosoft.com>,
        "K. Y. Srinivasan" <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>, Arnd Bergmann <arnd@...db.de>,
        "open list:GENERIC INCLUDE/ASM HEADER FILES" 
        <linux-arch@...r.kernel.org>
Subject: Re: [PATCH RFC v1 07/18] x86/hyperv: extract partition ID from
 Microsoft Hypervisor if necessary

On Wed, Sep 16, 2020 at 04:32:43PM +0000, Wei Liu wrote:
> On Tue, Sep 15, 2020 at 12:27:16PM +0200, Vitaly Kuznetsov wrote:
> > Wei Liu <wei.liu@...nel.org> writes:
> [...]
> > >  
> > > +void __init hv_get_partition_id(void)
> > > +{
> > > +	struct hv_get_partition_id *output_page;
> > > +	int status;
> > > +	unsigned long flags;
> > > +
> > > +	local_irq_save(flags);
> > > +	output_page = *this_cpu_ptr(hyperv_pcpu_output_arg);
> > > +	status = hv_do_hypercall(HVCALL_GET_PARTITION_ID, NULL, output_page) &
> > > +		HV_HYPERCALL_RESULT_MASK;
> > 
> > Nit: in this case status is 'u16', we can define it as such (instead of
> > signed int).
> 
> Fixed.
> 
> > 
> > > +	if (status != HV_STATUS_SUCCESS)
> > > +		pr_err("Failed to get partition ID: %d\n", status);
> > > +	else
> > > +		hv_current_partition_id = output_page->partition_id;
> > > +	local_irq_restore(flags);
> > > +
> > > +	/* No point in proceeding if this failed */
> > > +	BUG_ON(status != HV_STATUS_SUCCESS);
> > > +}
> > > +
> > >  /*
> > >   * This function is to be invoked early in the boot sequence after the
> > >   * hypervisor has been detected.
> > > @@ -440,6 +463,9 @@ void __init hyperv_init(void)
> > >  
> > >  	register_syscore_ops(&hv_syscore_ops);
> > >  
> > > +	if (hv_root_partition)
> > > +		hv_get_partition_id();
> > 
> > According to TLFS, partition ID is available when AccessPartitionId
> > privilege is granted. I'd suggest we check that instead of
> > hv_root_partition (and we can set hv_current_partition_id to something
> > like U64_MAX so we know it wasn't acuired). So the BUG_ON condition will
> > move here:
> > 
> >         hv_get_partition_id();
> >         BUG_ON(hv_root_partition && hv_current_partition_id == U64_MAX);
> > 
> 
> Good point. I will reorganize this a bit.

Actually, our current code never stashed the feature mask that contains
that privilege anywhere.  Getting access to it will require a few more
extra patches -- I would really like to rename those fields (features,
misc_features) inside ms_hyperv to something more appropriate.

We will gate it wit hv_root_partition anyway, since we a child VM may
not have the privilege, making an unconditional BUG_ON fatal.

All in all, the current code is not too bad. I intend to keep the
current structure for my RFC v2. I will see if I can find some time to
rework the feature mask extraction code and get that upstreamed first.

Wei.

> 
> Wei.