Re: Re: Need to zero pads in msghdr

[Rich Felker <dalias@libc.org>]

On Wed, Jan 25, 2017 at 11:46:44AM -0800, Andrei Vagin wrote:
> On Wed, Jan 25, 2017 at 11:40 AM, Szabolcs Nagy <nsz@port70.net> wrote:
> > * Andrei Vagin <avagin@gmail.com> [2017-01-25 10:56:22 -0800]:
> >> On Wed, Jan 25, 2017 at 8:42 AM, Andrei Vagin <avagin@gmail.com> wrote:
> >> > In this patch
> >> > http://git.musl-libc.org/cgit/musl/commit/arch/x86_64/bits/socket.h?id=7168790763cdeb794df52be6e3b39fbb021c5a64
> >> > you suppose that the kernel ignores the upper 32 bits of msg_iovlen,
> >> > but it doesn't, so pads in msghdr structures have to be zeroed before
> >> > calling sendmsg and recvmsg syscalls.
> >>
> >> Actually the problem is a bit different. In CRIU we use the msghdr
> >> structure from musl-libc, but in some cases we have to call raw system
> >> calls. We don't expect to have pads in structures and so we don't zero
> >> them.
> >
> > why do you need a raw syscall?
> 
> We inject our code into processes which are going to be dumped:
> https://criu.org/Parasite_code
> 
> And on restore we have to unmap old libc to restore process mappings.
> 
> >
> > (i think if you do raw syscalls you should use
> > your own linux syscall wrappers including typedefs
> > and macro defines, not libc ones, because the libc
> > can and does do all sorts of remapping of things to
> > workaround various mismatches between the posix
> > library api it provides and the linux syscall abi)
> 
> We know about this risk, but before this day we executed out test for
> glibc and it worked for everyone. Now we need think how to resolve the
> problem.

While you may hit problems elsewhere, I think there's a clean solution
here, just pre-zeroing the structure so that any possible padding is
zero. It's unfortunate that this is needed but it comes from the
kernel getting the structure definition wrong.

Rich