Re: [PATCH] xen: hypercall: fix out-of-bounds memcpy

From: Dan Carpenter <dan.carpenter@oracle.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Juergen Gross <jgross@suse.com>, Andi Kleen <ak@linux.intel.com>,
	Nicolas Pitre <nico@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jan Beulich <jbeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH] xen: hypercall: fix out-of-bounds memcpy
Date: Fri, 2 Feb 2018 19:34:01 +0300	[thread overview]
Message-ID: <20180202163401.zkshusaktxwrs6uj__42522.0766374425$1517589208$gmane$org@mwanda> (raw)
In-Reply-To: <CAK8P3a0Z2PMP-=e2Ga8kw196vWeAz_HC02ABQmDB9W_0Cmmr-Q@mail.gmail.com>

On Fri, Feb 02, 2018 at 05:11:02PM +0100, Arnd Bergmann wrote:
> On Fri, Feb 2, 2018 at 4:53 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > On Fri, Feb 02, 2018 at 04:32:31PM +0100, Arnd Bergmann wrote:
> >>       switch (cmd) {
> >> +     case EVTCHNOP_bind_interdomain:
> >> +             len = sizeof(struct evtchn_bind_interdomain);
> >> +             break;
> >
> > This was in the original code, but I'm slightly surpprised that we're
> > using a switch statement here instead of a table.  I would have thought
> > this is a fast path but I don't know xen at all.
> 
> I thought about using a table, but figured the switch statement
> had a lower risk of getting something slightly wrong during the
> conversion.
> 
> I would expect gcc to turn this into a table lookup, since all the
> constants are consecutive, but it should not really matter since
> this is only the fallback path for ancient Xen releases. When Xen
> guest support was first merged in 2007, it was already
> deprecated.
> 

Ah.  Ok.  That makes sense.

regards,
dan carpenter

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel