lkml.org 
[lkml]   [2015]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] tile: use si_int instead of si_ptr for compat_siginfo
(+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@ezchip.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> ---
>> 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



\
 
 \ /
  Last update: 2015-03-24 22:21    [W:0.054 / U:1.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site