[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANaxB-wG0-e7yOcfB2tOHewU3FcesrdsnthJo6Lrfc3hYhTSvg@mail.gmail.com>
Date: Wed, 25 Jan 2017 11:46:44 -0800
From: Andrei Vagin <avagin@...il.com>
To: musl@...ts.openwall.com, Andrei Vagin <avagin@...il.com>
Subject: Re: Re: Need to zero pads in msghdr
On Wed, Jan 25, 2017 at 11:40 AM, Szabolcs Nagy <nsz@...t70.net> wrote:
> * Andrei Vagin <avagin@...il.com> [2017-01-25 10:56:22 -0800]:
>> On Wed, Jan 25, 2017 at 8:42 AM, Andrei Vagin <avagin@...il.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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
