linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: Jessica Clarke <jrtc27@jrtc27.com>
Cc: linux-x86_64@vger.kernel.org, Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	X86 ML <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Brian Gerst <brgerst@gmail.com>
Subject: Re: [PATCH] x86: Fix x32 System V message queue syscalls
Date: Sun, 11 Oct 2020 20:02:21 -0700	[thread overview]
Message-ID: <CALCETrV4BFQ_Cdt98NTWnzQ1H4eJfzOpz_UO=Ak+i6jDQAmcrA@mail.gmail.com> (raw)
In-Reply-To: <20201012014837.14305-1-jrtc27@jrtc27.com>

On Sun, Oct 11, 2020 at 6:48 PM Jessica Clarke <jrtc27@jrtc27.com> wrote:
>
> 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.
>
> 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.

This has a few problems.

First, the 512-547 range is a legacy wart and we shouldn't extend it.
I thought I had documented this, but I didn't -- oops.  Patch sent.
The correct way to do this nowadays is to use the same number twice,
once for x64 and once for x32.  If you try to do this and encounter
problems with the build, please either fix them or let me know :)

Second, since this is an ABI issue, can you please include a little
test case that compiles for i386, x86_64 and x32, works correctly on
all three with whatever patch you send, and fails on x32 without the
patch?

Third, how does this interact with various libc implementations?
msgsnd(2) and msgrcv(2) have glibc wrappers.  Have they never been
tested on x32?

Fourth, if there is some deployed code that uses the buggy x32 path
and actually works by accident, do we risk breaking it if we fix the
bug?

--Andy

  reply	other threads:[~2020-10-12  3:02 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-12  1:48 [PATCH] x86: Fix x32 System V message queue syscalls Jessica Clarke
2020-10-12  3:02 ` Andy Lutomirski [this message]
2020-10-12  3:31   ` Jessica Clarke
2020-10-12 13:44     ` [PATCH v2] " Jessica Clarke
2020-10-30 19:21       ` Jessica Clarke
2020-10-31 23:30       ` Andy Lutomirski
2020-11-01  0:09         ` Jessica Clarke
2020-11-01  1:22         ` Rich Felker
2020-11-01  1:27           ` Jessica Clarke
2020-11-01  1:50             ` Rich Felker
2020-11-01 18:07               ` Andy Lutomirski
2020-11-01 18:15                 ` Jessica Clarke
2020-11-01 18:27                   ` Jessica Clarke
2020-11-01 21:01                     ` Rich Felker
2020-11-16  0:55                       ` Jessica Clarke
2020-12-06  0:01                         ` Jessica Clarke
2020-12-06 22:55                           ` Andy Lutomirski
2023-08-01  0:43                             ` Harald van Dijk
2023-08-01  1:38                               ` Jessica Clarke
2023-08-01  2:53                                 ` Rich Felker
2023-08-01 12:13                                   ` Harald van Dijk
2023-09-10 23:33                                 ` [PATCH 1/2] uapi: Stop using __kernel_long_t in struct msgbuf Harald van Dijk
2023-09-10 23:33                                 ` [PATCH 2/2] uapi: Remove struct msgbuf, struct ipc_kludge Harald van Dijk
2023-08-01  7:15                               ` [PATCH v2] x86: Fix x32 System V message queue syscalls Florian Weimer
2023-08-01 12:15                                 ` Harald van Dijk
2023-09-10 23:40                                   ` Harald van Dijk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALCETrV4BFQ_Cdt98NTWnzQ1H4eJfzOpz_UO=Ak+i6jDQAmcrA@mail.gmail.com' \
    --to=luto@kernel.org \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jrtc27@jrtc27.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-x86_64@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).