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

[Boris Ostrovsky]

On 02/04/2018 10:35 AM, Arnd Bergmann wrote:
> On Sat, Feb 3, 2018 at 6:08 PM, Boris Ostrovsky
> <boris.ostrovsky@xxxxxxxxxx> wrote:
> > On 02/03/2018 10:12 AM, Arnd Bergmann wrote:
> > > On Sat, Feb 3, 2018 at 12:33 AM, Boris Ostrovsky
> > > <boris.ostrovsky@xxxxxxxxxx> wrote:
> > > > On 02/02/2018 10:32 AM, Arnd Bergmann wrote:
> > > > > The legacy hypercall handlers were originally added with
> > > > > a comment explaining that "copying the argument structures in
> > > > > HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local
> > > > > variable is sufficiently safe" and only made sure to not write
> > > > > past the end of the argument structure, the checks in linux/string.h
> > > > > disagree with that, when link-time optimizations are used:
> > > > >
> > > > > In function 'memcpy',
> > > > >       inlined from 'pirq_query_unmask' at drivers/xen/fallback.c:53:2,
> > > > >       inlined from '__startup_pirq' at
> > > > > drivers/xen/events/events_base.c:529:2,
> > > > >       inlined from 'restore_pirqs' at
> > > > > drivers/xen/events/events_base.c:1439:3,
> > > > >       inlined from 'xen_irq_resume' at
> > > > > drivers/xen/events/events_base.c:1581:2:
> > > > > include/linux/string.h:350:3: error: call to '__read_overflow2' declared
> > > > > with attribute error: detected read beyond size of object passed as 2nd
> > > > > parameter
> > > > >      __read_overflow2();
> > > > >      ^
> > > > > make[3]: *** [ccLujFNx.ltrans15.ltrans.o] Error 1
> > > > > make[3]: Target 'all' not remade because of errors.
> > > > > lto-wrapper: fatal error: make returned 2 exit status
> > > > > compilation terminated.
> > > > > ld: error: lto-wrapper failed
> > > > >
> > > > > This changes the functions so that each argument is accessed with
> > > > > exactly the correct length based on the command code.
> > > > >
> > > > > Fixes: cf47a83fb06e ("xen/hypercall: fix hypercall fallback code for
> > > > > very old hypervisors")
> > > > > Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
> > > > > ---
> > > > >    drivers/xen/fallback.c | 94
> > > > > ++++++++++++++++++++++++++++----------------------
> > > > >    1 file changed, 53 insertions(+), 41 deletions(-)
> > > > >
> > > > >         default:
> > > > > -             WARN_ON(rc != -ENOSYS);
> > > > > -             break;
> > > > > +             return -ENOSYS;
> > > > >         }
> > > > >
> > > > > +     memcpy(&op.u, arg, len);
> > > > > +     rc = _hypercall1(int, event_channel_op_compat, &op);
> > > > > +     memcpy(arg, &op.u, len);
> > > >
> > > >
> > > > We don't copy back for all commands, only those that are COPY_BACK.
> > >
> > > Not sure what you mean. Is it harmful to copy back the data for the others
> > > in any way? Otherwise I wouldn't micro-optimize this.
> >
> >
> > I should have checked the original commit for fallback.c --- the code that
> > it replaced was doing copybacks for all hypercalls and selective copybacks
> > is an optimization introduced in that commit.
> It was not an optimization but a correctness fix to avoid overflowing
> the caller stack on the copy-back operation. What I tried to explain
> in my commit message is that the same fix is also needed on
> the copy-out before it. It's only a read access beyond the end
> of a local variable, but not both the static checks and kasan-stack
> get alarmed about it.

Yes, I understand that. I was referring to:

ÂÂÂ Move the fallback code into out-of-line functions, and handle all of
ÂÂÂ the operations known by this old a hypervisor individually: *Some don't
ÂÂÂ require copying back anything at all*, and for the rest use the
ÂÂÂ individual argument structures' sizes rather than the container's

in the original commit. I.e. prior to that commit we *were* copying back 
for all commands (although possibly with potentially incorrect size). So 
not copying back for some commands was an optimization.

In any case,

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>