linux-kernel - Re: [PATCH v2 17/17] x86/hyperv: handle IO-APIC when running as root

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: <20201113160458.fyalsxpse5bg25dd@liuwe-devbox-debian-v2>
Date:   Fri, 13 Nov 2020 16:04:58 +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 <nunodasneves@...ux.microsoft.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>
Subject: Re: [PATCH v2 17/17] x86/hyperv: handle IO-APIC when running as root

On Fri, Nov 13, 2020 at 04:01:58PM +0000, Wei Liu wrote:
> On Thu, Nov 12, 2020 at 05:56:41PM +0100, Vitaly Kuznetsov wrote:
> [...]
> > > +static unsigned int hv_ioapic_startup_irq(struct irq_data *data)
> > > +{
> > > +	u16 status;
> > > +	struct IO_APIC_route_entry ire;
> > > +	u32 vector;
> > > +	struct irq_cfg *cfg;
> > > +	int ioapic;
> > > +	u8 ioapic_pin;
> > > +	int ioapic_id;
> > > +	int gsi;
> > > +	union entry_union eu;
> > > +	struct cpumask *affinity;
> > > +	int cpu, vcpu;
> > > +	struct hv_interrupt_entry entry;
> > > +	struct mp_chip_data *mp_data = data->chip_data;
> > > +
> > > +	gsi = data->irq;
> > > +	cfg = irqd_cfg(data);
> > > +	affinity = irq_data_get_effective_affinity_mask(data);
> > > +	cpu = cpumask_first_and(affinity, cpu_online_mask);
> > > +	vcpu = hv_cpu_number_to_vp_number(cpu);
> > > +
> > > +	vector = cfg->vector;
> > > +
> > > +	ioapic = mp_find_ioapic(gsi);
> > > +	ioapic_pin = mp_find_ioapic_pin(ioapic, gsi);
> > > +	ioapic_id = mpc_ioapic_id(ioapic);
> > > +	ire = ioapic_read_entry(ioapic, ioapic_pin);
> > > +
> > > +	/*
> > > +	 * Always try unmapping. We do not have visibility into which whether
> > > +	 * an IO-APIC has been mapped or not. We can't use chip_data because it
> > > +	 * already points to mp_data.
> > > +	 *
> > > +	 * We don't use retarget interrupt hypercalls here because Hyper-V
> > > +	 * doens't allow root to change the vector or specify VPs outside of
> > > +	 * the set that is initially used during mapping.
> > > +	 */
> > > +	status = hv_unmap_ioapic_interrupt(gsi);
> > > +
> > > +	if (!(status == HV_STATUS_SUCCESS || status == HV_STATUS_INVALID_PARAMETER)) {
> > > +		pr_debug("%s: unexpected unmap status %d\n", __func__, status);
> > > +		return -1;
> > 
> > Nit: the function returns 'unsigned int' but I see other 'irq_startup'
> > routines return negative values too, however, they tend to returd
> > '-ESOMETHING' so maybe -EFAULT here?
> > 
> 
> The return type should've been int instead. That's what the function
> signature in struct irq_chip looks like.

Actually it is unsigned int. Oh well.

Wei.