linux-kernel - Re: [PATCH 3/5] x86/ioapic: Handle Extended Destination ID field in RTE

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: <7ffc9956b668cc353dc7b1fcc423f3f786168d4d.camel@infradead.org>
Date:   Thu, 08 Oct 2020 18:05:42 +0100
From:   David Woodhouse <dwmw2@...radead.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     x86@...nel.org, kvm <kvm@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Paolo Bonzini <pbonzini@...hat.com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/5] x86/ioapic: Handle Extended Destination ID field in
 RTE

On Thu, 2020-10-08 at 11:12 +0200, Peter Zijlstra wrote:
> On Wed, Oct 07, 2020 at 01:20:44PM +0100, David Woodhouse wrote:
> > @@ -1861,7 +1863,8 @@ static void ioapic_configure_entry(struct irq_data *irqd)
> >  	 * ioapic chip to verify that.
> >  	 */
> >  	if (irqd->chip == &ioapic_chip) {
> > -		mpd->entry.dest = cfg->dest_apicid;
> > +		mpd->entry.dest = cfg->dest_apicid & 0xff;
> > +		mpd->entry.ext_dest = cfg->dest_apicid >> 8;
> >  		mpd->entry.vector = cfg->vector;
> >  	}
> >  	for_each_irq_pin(entry, mpd->irq_2_pin)
> 
> All the other sites did memset(0) before the assignment, and this the
> extra unconditional write of 0 to ext_dest is harmless.
> 
> This might be true for this site too, but it wasn't immediately obvious.

Yeah. Really, that whole 16-bit field ought to be called
'msi_addr_bits_19_to_4' since there's no interpretation by the IOAPIC
and it's *just* passed on in the MSI cycle. See my later patch which
stops making them up for ourselves in the IOAPIC code and *just*
swizzles them out of the MSI message which is composed for us by
upstream.

In this case, since this piece of code is based on the knowledge that
the upstream controller is accepting MSI in the x86 Compatibility
Format, those seven bits are never going to have been used for anything
else.

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5174 bytes)