From: Andy Lutomirski <luto@amacapital.net>
To: "Amanieu d'Antras" <amanieu@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Oleg Nesterov <oleg@redhat.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Linux MIPS Mailing List <linux-mips@linux-mips.org>,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
sparclinux@vger.kernel.org,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Kenton Varda <kenton@sandstorm.io>
Subject: Re: [PATCH v2 00/20] Fix handling of compat_siginfo_t
Date: Sat, 7 Nov 2015 21:09:27 -0800 [thread overview]
Message-ID: <CALCETrWKK_REdX7TJO8X7jC=8k=YdgJH_txXpC4Pdzn-tukg5A@mail.gmail.com> (raw)
In-Reply-To: <1446684640-4112-1-git-send-email-amanieu@gmail.com>
On Wed, Nov 4, 2015 at 4:50 PM, Amanieu d'Antras <amanieu@gmail.com> wrote:
> One issue that isn't resolved in this series is sending signals between a 32-bit
> process and 64-bit process. Sending a si_int will work correctly, but a si_ptr
> value will likely get corrupted due to the different layouts of the 32-bit and
> 64-bit siginfo_t structures.
This is so screwed up it's not even funny.
A 64-bit big-endian compat calls rt_sigqueueinfo. It passes in (among
other things) a sigval_t. The kernel can choose to interpret it as a
pointer (call it p) or an integer (call it i). Then (unsigned long)p
= (i<<32) | [something]. If the number was an integer to begin with
*and* user code zeroed out the mess first, then [something] will be 0.
Regardless, p != i unless they're both zero.
If the result gets delivered to a signalfd, then it's plausible that
everything could work. If it gets delivered to a 64-bit siginfo, then
all is well because it's in exactly the same screwed up state it was
in when the signal gets sent.
If, however, it's delivered to a compat task, wtf is the kernel
supposed to do? We're effectively supposed to convert a 64-bit
sigval_t to a 32-bit sigval_t. On a little-endian architecture, we
can fudge it because it doesn't really matter whether we consider the
pointer or the int to be authoritative. I think that, on big-endian,
we're screwed.
BTW, x86 has its own set of screwups here. Somehow cr2 and error_code
ended up as part of ucontext instead of siginfo, which makes
absolutely no sense to me and bloats task_struct.
--Andy
next prev parent reply other threads:[~2015-11-08 5:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-05 0:50 [PATCH v2 00/20] Fix handling of compat_siginfo_t Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 01/20] compat: Add generic compat_siginfo_t Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 02/20] compat: Add generic copy_siginfo_{to,from}_user32 Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 03/20] x86: Update compat_siginfo_t to be closer to the generic version Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 04/20] x86: Rewrite copy_siginfo_{to,from}_user32 Amanieu d'Antras
2015-11-05 2:29 ` H. Peter Anvin
2015-11-05 0:50 ` [PATCH v2 05/20] mips: Clean up compat_siginfo_t Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 06/20] mips: Use generic copy_siginfo_{to,from}_user32 Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 07/20] arm64: Use generic compat_siginfo_t Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 08/20] arm64: Use generic copy_siginfo_{to,from}_user32 Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 09/20] parisc: Use generic compat_siginfo_t Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 10/20] parsic: Use generic copy_siginfo_{to,from}_user32 Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 11/20] s390: Use generic compat_siginfo_t Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 12/20] s390: Use generic copy_siginfo_{to,from}_user32 Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 13/20] powerpc: Use generic compat_siginfo_t Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 14/20] powerpc: Use generic copy_siginfo_{to,from}_user32 Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 15/20] tile: Use generic compat_siginfo_t Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 16/20] tile: Use generic copy_siginfo_{to,from}_user32 Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 17/20] sparc: Use generic compat_siginfo_t Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 18/20] sparc: Use generic copy_siginfo_{to,from}_user32 Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 19/20] signalfd: Fix some issues in signalfd_copyinfo Amanieu d'Antras
2015-11-05 0:50 ` [PATCH v2 20/20] signal: Remove unnecessary zero-initialization of siginfo_t Amanieu d'Antras
2015-11-08 5:09 ` Andy Lutomirski [this message]
2015-11-09 15:12 ` [PATCH v2 00/20] Fix handling of compat_siginfo_t Oleg Nesterov
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='CALCETrWKK_REdX7TJO8X7jC=8k=YdgJH_txXpC4Pdzn-tukg5A@mail.gmail.com' \
--to=luto@amacapital.net \
--cc=amanieu@gmail.com \
--cc=kenton@sandstorm.io \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=oleg@redhat.com \
--cc=sparclinux@vger.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).