[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK8P3a1MJf7-gyZKe8hNaZnahPcatTveBM_zKGzYx9wEh0GXOg@mail.gmail.com>
Date: Mon, 16 May 2022 23:07:53 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Maxim Zhukov <crazycdeveloper@...il.com>, chi.minghao@....com.cn,
varad.gautam@...e.com, Arnd Bergmann <arnd@...db.de>,
Shakeel Butt <shakeelb@...gle.com>, vasily.averin@...ux.dev,
Manfred Spraul <manfred@...orfullife.com>,
Davidlohr Bueso <dbueso@...e.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Maxim Zhukov <mussitantesmortem@...il.com>
Subject: Re: [RFC PATCH 1/1] ipc, sem: fix backward compatibility with x86-32 kernels
On Mon, May 16, 2022 at 10:06 PM Andrew Morton
<akpm@...ux-foundation.org> wrote:
>
> On Sun, 15 May 2022 23:01:03 +0300 Maxim Zhukov <crazycdeveloper@...il.com> wrote:
>
> > Since with commit 275f22148e87 ("ipc: rename old-style shmctl/semctl/msgctl syscalls")
> > we have changed behavior:
> >
> > ksys_semctl lost parse ipc version (ipc_parse_version), because the
> > new syscall works with IPC_64 only, but the parse function has some
> > side effect - it removes IPC_64 bit from `cmd`.
> >
> > Some libc forced sends IPC_64 bit in semctl syscall[1][2][3], this leads to
> > a bug - X86-32 kernel does not have compat headers and does not
> > correctly parse received command (cmd) from semctl syscall: cmd have actual
> > command and IPC_64 bit, thus throw EINVAL error in ksys_semctl
> >
> > This commit forcibly removes IPC_64 bit from the cmd for restore
> > backward compatibility.
> >
> > [1]: https://elixir.bootlin.com/uclibc-ng/v1.0.40/source/libc/misc/sysvipc/sem.c#L58
> > [2]: https://elixir.bootlin.com/musl/v1.2.3/source/src/ipc/semctl.c#L48 -> https://elixir.bootlin.com/musl/v1.2.3/source/src/ipc/ipc.h#L22
> > [3]: https://elixir.bootlin.com/glibc/glibc-2.35/source/sysdeps/unix/sysv/linux/semctl.c#L124
> >
>
> Thanks.
>
> 275f22148e87 was three years ago. Can you suggest why it took so long
> for this to be discovered?
I think it only shows up with a uclibc-ng built against 32-bit kernel headers
from linux-5.1 or new for m68k, mips-o32, powerpc, s390, sh, sparc, and
x86-32 (list is from my original commit 275f22148e87), not for the more
popular musl or glibc libraries.
If sysvipc is used this rarely on uclibc-ng, maybe we can fix it by making
it behave the same way as glibc instead? I agree the kernel interface is
easy to get wrong here because of the subtle difference between ipc()
and semctl(), but this was an intentional design choice at the time, and
it did not affect the behavior of the existing syscalls, only the newly
added calls.
Arnd
Powered by blists - more mailing lists