Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
From:   Jessica Clarke <jrtc27@jrtc27.com>
In-Reply-To: <20201012134444.1905-1-jrtc27@jrtc27.com>
Date:   Fri, 30 Oct 2020 19:21:03 +0000
Cc:     Andy Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
        linux-kernel@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <159B3D01-132C-4F56-ABF0-72A8D5958A29@jrtc27.com>
References: <1156938F-A9A3-4EE9-B059-2294A0B9FBFE@jrtc27.com>
 <20201012134444.1905-1-jrtc27@jrtc27.com>
To:     linux-x86_64@vger.kernel.org
Precedence: bulk

> On 12 Oct 2020, at 14:44, Jessica Clarke <jrtc27@jrtc27.com> wrote:
>=20
> POSIX specifies that the first field of the supplied msgp, namely =
mtype,
> is a long, not a __kernel_long_t, and it's a user-defined struct due =
to
> the variable-length mtext field so we can't even bend the spec and =
make
> it a __kernel_long_t even if we wanted to. Thus we must use the compat
> syscalls on x32 to avoid buffer overreads and overflows in msgsnd and
> msgrcv respectively.
>=20
> Due to erroneously including the first 4 bytes of mtext in the mtype
> this would previously also cause non-zero msgtyp arguments for msgrcv =
to
> search for the wrong messages, and if sharing message queues between =
x32
> and non-x32 (i386 or x86_64) processes this would previously cause =
mtext
> to "move" and, depending on the direction and ABI combination, lose =
the
> first 4 bytes.
>=20
> Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
> ---

Ping?

Jess

>=20
> I have verified that the test at the end of [1] now gives the correct
> result on x32 ("PAYL" not "PAY" as I erroneously claimed it should be =
in
> the above email) and that both i386 and amd64 give the same output =
with
> that test as before.
>=20
> [1] <1156938F-A9A3-4EE9-B059-2294A0B9FBFE@jrtc27.com>
>=20
> Changes since v1:
> * Uses the same syscall numbers for x32 as amd64 and the current x32
>   rather than (further) breaking ABI by allocating new ones from the
>   legacy x32 range
>=20
> arch/x86/entry/syscalls/syscall_64.tbl | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>=20
> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl =
b/arch/x86/entry/syscalls/syscall_64.tbl
> index f30d6ae9a..f462123f3 100644
> --- a/arch/x86/entry/syscalls/syscall_64.tbl
> +++ b/arch/x86/entry/syscalls/syscall_64.tbl
> @@ -77,8 +77,10 @@
> 66	common	semctl			sys_semctl
> 67	common	shmdt			sys_shmdt
> 68	common	msgget			sys_msgget
> -69	common	msgsnd			sys_msgsnd
> -70	common	msgrcv			sys_msgrcv
> +69	64	msgsnd			sys_msgsnd
> +69	x32	msgsnd			compat_sys_msgsnd
> +70	64	msgrcv			sys_msgrcv
> +70	x32	msgrcv			compat_sys_msgrcv
> 71	common	msgctl			sys_msgctl
> 72	common	fcntl			sys_fcntl
> 73	common	flock			sys_flock
> --=20
> 2.28.0
>=20