[strace/strace] sysvipc handling is time64-incompatible (#116)

[arndb]

On Tue, Jan 14, 2020 at 12:29 PM Dmitry V. Levin
<notifications at github.com> wrote:
> On Tue, Jan 14, 2020 at 02:55:08AM -0800, arndb wrote:
> > > sparc:
> > > according to struct compat_ipc64_perm defined in
> > > arch/sparc/include/asm/compat.h,
> > > the type of uid is __compat_uid32_t aka u32,
> > > but, according to struct ipc64_perm defined in
> > > arch/sparc/include/uapi/asm/ipcbuf.h,
> > > the type of uid is __kernel_uid_t which is defined to unsigned short on
> > > sparc.
> > >
> > > I suppose the regression was introduced by commit
> > > 83c86984bff2d793c91eb710af7857828b9ddb49 aka v2.6.29-rc1~501^2~6
> > >
> > > If my guess is correct, then the only working form of IPC_STAT on sparc32
> > > since that commit is sparc64 in compat mode.
> >
> > Ok, so this would be a bug with what sysvipc on sparc32 does in the kernel,
> > rather than a bug of the uapi headers not describing what it does, correct?
>
> Not really, from strace testsuite perspective it looks like tracing of
> 32-bit processes by 64-bit strace produces wrong results on sparc64 when
> strace is built with uapi headers instead of glibc headers, and this
> happens because arch/sparc/include/uapi/asm/ipcbuf.h does not describe
> the same structure the sparc64 kernel works with in to_compat_ipc64_perm.
>
> So I'd say it's a bug of arch/sparc/include/uapi/asm/ipcbuf.h not
> describing what ipc/compat.c actually does.

Fair enough. The header matches the behavior of the native kernel,
but both the header and the kernel are wrong, you are just lucky
that in compat mode the glibc headers describe what the kernel does.

> > Adding the SPARC list and maintainer to Cc. Yes, I read it the same way.
> > In particular, Sam back then wrote
> >
> > commit 83c86984bff2d793c91eb710af7857828b9ddb49
> > Author: Sam Ravnborg <sam at ravnborg.org>
> > Date: Sun Jan 4 15:44:22 2009 -0800
> >
> > sparc: unify ipcbuf.h
> >
> > The ony difference is the size of the mode.
> > sparc has extra padding to compensate for this.
> >
> > Signed-off-by: Sam Ravnborg <sam at ravnborg.org>
> > Signed-off-by: David S. Miller <davem at davemloft.net>
> >
> > However, aside from mode, the other fields that were changed are
> > 'uid', 'gid', 'cuid' and 'cgid'. It's been 11 years since that ABI change,
> > so I wonder if anyone has started relying on the changed behavior
> > in the meantime, or sparc32 users just don't use sysvipc.
> >
> > I checked glibc and uclibc-ng, and both use the pre-2009 version
> > of the ABI. I also checked the leon-linux patches from
> > https://www.gaisler.com/anonftp/linux/linux-2.6/kernel/ to see
> > if they had already come across this, but there is no fix either.
>
> ... this definitely means users of sparc32 kernel (if any) don't use
> IPC_STAT since 2009.

I can see that it's being tested for each glibc release,
e.g. https://sourceware.org/glibc/wiki/Release/2.30#SPARC_.2832-bit.29
and it's probably a release blocker, but I guess that this has also
been done on compat mode since at least 2009, rather than
on native 32-bit sparc hardware.

       Arnd


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/strace/strace/issues/116#issuecomment-574133907
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20200114/6fc3dc11/attachment.html>