All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andy Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Q: Can we get rid of __copy_siginfo_to_user32?
Date: Tue, 10 Apr 2018 21:09:11 -0700	[thread overview]
Message-ID: <CALCETrVR1qHCndoaqXWosy8ckMTyT2RequQTgg0MZUw_sMPwwQ@mail.gmail.com> (raw)
In-Reply-To: <87d0z6ttxe.fsf@xmission.com>

> On Apr 10, 2018, at 6:26 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>
>
> Andy,
>
> I am looking at copy_siginfo_to_user32 and find it very unfortunate
> that x86 with _sigchld_x32 needs to be the odd man out.  I am looking
> at ways to simplify the special case.
>
> The core of the special case comes from:
> exit_to_usermode_loop
>  do_signal
>    handle_signal
>       setup_rt_frame
>
>
> In setup_rt_frame the code looks at ksig to see which kind of signal
> frame should be written for the signal.
>
> This leads to the one case in the kernel where copy_siginfo_to_user32
> does not use is_ia32_syscall() or is_x32_syscall() to see which kind of
> signal frame it needs to create.
>
> Andy, since you have been all over the entry point code in recent years
> do you know if we allow tasks that can do both ia32 and x86_64 system
> calls?  That seems to be what we the testing of ksig to see which kind
> of signal frame to setup is all about.

We do :(

> If we don't allow mixed abi's on x86_64 then can I see if I have a ia32
> task in setup_rt_frame by just calling is_ia32_syscall()?
>
> If we do allow mixed abi's do you know if it would be safe to
> temporarily play with orig_ax or current_thread_info()->status?

Maybe, but it’s a real minefield. I think the right fix is to use
sa_flags's SA_X32_ABI bit instead for the sigchld bit.  In general,
the is_..._syscall() helpers can't be expected to return anything
valid in any context other than a syscall, and handle_signal() is not
a syscall.

>
> My goal is to write two wrappers: copy_siginfo_to_user32_ia32, and
> copy_siginfo_to_user32_x32 around the ordinary copy_siginfo_to_user32.
> With only a runtime test to see which ABI we need to implement.
>
> Aka change:
>>    case SIL_CHLD:
>>        to->si_pid    = from->si_pid;
>>        to->si_uid    = from->si_uid;
>>        to->si_status = from->si_status;
>> #ifdef CONFIG_X86_X32_ABI
>>        if (x32_ABI) {
>>            to->_sifields._sigchld_x32._utime = from->si_utime;
>>            to->_sifields._sigchld_x32._stime = from->si_stime;
>>        } else
>> #endif
>>        {
>>            to->si_utime = from->si_utime;
>>            to->si_stime = from->si_stime;
>>        }
>>        break;
> to something like:
>>    case SIL_CHLD:
>>        to->si_pid    = from->si_pid;
>>        to->si_uid    = from->si_uid;
>>        to->si_status = from->si_status;
>> #ifdef CONFIG_X86_X32_ABI
>>        if (!is_ia32_syscall()) {
>>            to->_sifields._sigchld_x32._utime = from->si_utime;
>>            to->_sifields._sigchld_x32._stime = from->si_stime;
>>        } else
>> #endif
>>        {
>>            to->si_utime = from->si_utime;
>>            to->si_stime = from->si_stime;
>>        }
>>        break;
>

Makes sense, but can you get to sa_flags in there instead?

FWIW, I have a branch here:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=execve

that contains a *massive* cleanup of some other x86 signal stuff.  I
need to dust it off and test it better.

  reply	other threads:[~2018-04-11  4:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-11  1:26 Q: Can we get rid of __copy_siginfo_to_user32? Eric W. Biederman
2018-04-11  4:09 ` Andy Lutomirski [this message]
2018-04-11 16:11   ` Q: Do si_time and si_utime need to be 64bit for y2038? Eric W. Biederman
2018-04-11 16:11     ` Eric W. Biederman
2018-04-11 20:13     ` Arnd Bergmann
2018-04-11 22:03       ` Eric W. Biederman

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=CALCETrVR1qHCndoaqXWosy8ckMTyT2RequQTgg0MZUw_sMPwwQ@mail.gmail.com \
    --to=luto@amacapital.net \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.