Re: [PATCH] tile: use si_int instead of si_ptr for compat_siginfo
From: Chris Metcalf
Date: Tue Mar 24 2015 - 16:52:18 EST
(+s390 and parisc maintainers)
On 03/23/2015 08:02 AM, Catalin Marinas wrote:
On Mon, Mar 16, 2015 at 03:04:05PM -0400, Chris Metcalf wrote:
To be compatible with the generic get_compat_sigevent(), the
copy_siginfo_to_user32() and thus copy_siginfo_from_user32()
have to use si_int instead of si_ptr. Using si_ptr means that
for the case of ILP32 compat code running in big-endian mode,
we would end up copying the high 32 bits of the pointer value
into si_int instead of the desired low 32 bits.
Signed-off-by: Chris Metcalf <cmetcalf@xxxxxxxxxx>
Cc: Catalin Marinas <catalin.marinas@xxxxxxx>
---
arch/tile/kernel/compat_signal.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/tile/kernel/compat_signal.c b/arch/tile/kernel/compat_signal.c
index 8c5abf2e4794..bca13054afb4 100644
--- a/arch/tile/kernel/compat_signal.c
+++ b/arch/tile/kernel/compat_signal.c
@@ -68,7 +68,7 @@ int copy_siginfo_to_user32(struct compat_siginfo __user *to, const siginfo_t *fr
if (from->si_code < 0) {
err |= __put_user(from->si_pid, &to->si_pid);
err |= __put_user(from->si_uid, &to->si_uid);
- err |= __put_user(ptr_to_compat(from->si_ptr), &to->si_ptr);
+ err |= __put_user(from->si_int, &to->si_int);
} else {
/*
* First 32bits of unions are always present:
@@ -93,8 +93,7 @@ int copy_siginfo_to_user32(struct compat_siginfo __user *to, const siginfo_t *fr
break;
case __SI_TIMER >> 16:
err |= __put_user(from->si_overrun, &to->si_overrun);
- err |= __put_user(ptr_to_compat(from->si_ptr),
- &to->si_ptr);
+ err |= __put_user(from->si_int, &to->si_int);
break;
It's usually the __SI_TIMER and __SI_MESGQ cases that matters here (the
latter already handled). I'm not entirely sure about the si_code < 0
change.
To be honest, I'm not even sure what path sets si_code < 0. I see
that that is SI_FROMUSER(), but I don't see where it gets set.
In any case, I guess a risk here is that of a 64-bit process doing a
sigqueue()
targeting a 32-bit process. It seems like an impossible problem for the
32-bit process to know whether the 64-bit process wrote a 32-bit pointer
to the 64-bit sival_ptr field (and thus we should deliver the second 32-bit
word of the union sigval to the 32-bit user), or if the 64-bit process wrote
a 32-bit value to the 32-bit sival_int field (and thus we should deliver
the
first 32-bit word of the union sigval). Little-endian makes some things
a little bit easier :-)
All that said, my inclination is to use si_int here just because that's what
we're using elsewhere. But I'm not entirely sure either.
/* This is not generated by the kernel as of now. */
case __SI_RT >> 16:
@@ -110,7 +109,6 @@ int copy_siginfo_to_user32(struct compat_siginfo __user *to, const siginfo_t *fr
int copy_siginfo_from_user32(siginfo_t *to, struct compat_siginfo __user *from)
{
int err;
- u32 ptr32;
if (!access_ok(VERIFY_READ, from, sizeof(struct compat_siginfo)))
return -EFAULT;
@@ -121,8 +119,7 @@ int copy_siginfo_from_user32(siginfo_t *to, struct compat_siginfo __user *from)
err |= __get_user(to->si_pid, &from->si_pid);
err |= __get_user(to->si_uid, &from->si_uid);
- err |= __get_user(ptr32, &from->si_ptr);
- to->si_ptr = compat_ptr(ptr32);
+ err |= __get_user(to->si_int, &from->si_int);
We have a memset(to, 0, sizeof(*to)) on arm64 in this function but I
can't see it on tile. Some members or even half of si_ptr would be left
uninitialised.
So here we presumably have the reverse problem, which is a 32-bit
process doing a sigqueue() to a 64-bit process. If the 64-bit process
inspects the sival_ptr, it does seem like it might find garbage in it.
But it also doesn't seem portable in much the same way as the
reverse direction; for a 32-bit process to signal a 64-bit process means
the 64-bit process can't read si_ptr or it will get different values
depending on what endianness is in force, so garbage is only part
of the problem.
I was modeling this code on the very similar code for parisc and s390.
I've added their maintainers to the cc list for this email thread.
I see that x86 uses si_ptr in its equivalent code, but of course it has no
issues with big-endianness.
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/