All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Safonov <dsafonov@virtuozzo.com>
To: Andy Lutomirski <luto@amacapital.net>, Oleg Nesterov <oleg@redhat.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	Andy Lutomirski <luto@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>, X86 ML <x86@kernel.org>
Subject: Re: [RFC 3/3] x86/ptrace: down with test_thread_flag(TIF_IA32)
Date: Mon, 25 Apr 2016 21:13:15 +0300	[thread overview]
Message-ID: <571E5E3B.7020806@virtuozzo.com> (raw)
In-Reply-To: <571E5D51.2060809@virtuozzo.com>

On 04/25/2016 09:09 PM, Dmitry Safonov wrote:
> On 04/25/2016 08:14 PM, Dmitry Safonov wrote:
>> On 04/25/2016 07:53 PM, Andy Lutomirski wrote:
>>> On Mon, Apr 25, 2016 at 9:12 AM, Dmitry Safonov 
>>> <dsafonov@virtuozzo.com> wrote:
>>>> As the task isn't executing at the moment of {GET,SET}REGS,
>>>> return regset that corresponds to code selector.
>>>> So, for i386 elf binary that changed it's CS to __USER_CS
>>>> it will return full x86_64 register set.
>>>>
>>>> That will change ABI: i.e, strace uses returned register size
>>>> to determine, in which mode the application is.
>>>> With the current ABI that way is buggy:
>>> Oleg, any comment here?
>>>
>>>> int main(int argc, char **argv, char **envp)
>>>> {
>>>>          printf("Here we exit\n");
>>>>          fflush(stdout);
>>>>          asm volatile ("int $0x80" : : "a" (__NR_exit), "D" (1));
>>>>          printf("After exit\n");
>>>>
>>>>          return 0;
>>>> }
>>>>
>>>> This program will confuse strace:
>>>>
>>>> [tst]$ strace ./confuse 2>&1 | tail
>>>> brk(0x1ca1000)                          = 0x1ca1000
>>>> write(1, "Here we exit\n", 13Here we exit
>>>> )          = 13
>>>> exit(1)                                 = ?
>>>> <... exit resumed> strace: _exit returned!
>>>> )                    = ?
>>>> write(1, "After exit\n", 11After exit
>>>> )            = 11
>>>> exit_group(0)                           = ?
>>>> +++ exited with 0 +++
>>>>
>>>> So this ABI change should make PTRACE_GETREGSET more reliable and
>>>> this will be another step to drop TIF_{IA32,X32} flags.
>>> Does strace start working again with this change?  I suspect that
>>> we'll eventually have to expose syscall_get_arch directly through
>>> ptrace, but that's a project for another day.
>>
>> Oh, crap, not yet - seems like, I failed with my test.
>> I'll resend this patch as will get it fixed, sorry.
>
> I find out, what I have changed (and broke test):
> > if (!user_64bit_mode(task_pt_regs(task)))
> was
> > if (task_thread_info(task)->status & TS_COMPAT)
>
> That way the test runs now:
>> brk(NULL)                               = 0x1145000
>> brk(0x1167000)                          = 0x1167000
>> write(1, "Here we exit\n", 13Here we exit
>> )          = 13
>> strace: [ Process PID=1608 runs in 32 bit mode. ]
>> umask(0)                                = 022

And that seems to be right as __NR_exit for amd64
is 60, which is the same as __NR_umask for i386.

>> strace: [ Process PID=1608 runs in 64 bit mode. ]
>> write(1, "After exit\n", 11After exit
>> )            = 11
>> exit_group(0)                           = ?
>> +++ exited with 0 +++
>
> But I changed on signal patch rebase and now I'm
> thinking: should it be
> > if (task_thread_info(task)->status & TS_COMPAT || 
> !user_64bit_mode(task_pt_regs(task)))
> or what?
> Should we count program that does compat syscall
> as compatible even if it's in 64-bit mode?
>


-- 
Regards,
Dmitry Safonov

  reply	other threads:[~2016-04-25 18:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-25 16:12 [RFC 1/3] x86/signal: add SA_{X32,IA32}_ABI sa_flags Dmitry Safonov
2016-04-25 16:12 ` [RFC 2/3] x86/coredump: use core regs, rather that TIF_IA32 flag Dmitry Safonov
2016-04-25 16:51   ` Andy Lutomirski
2016-04-25 16:12 ` [RFC 3/3] x86/ptrace: down with test_thread_flag(TIF_IA32) Dmitry Safonov
2016-04-25 16:53   ` Andy Lutomirski
2016-04-25 17:14     ` Dmitry Safonov
2016-04-25 18:09       ` Dmitry Safonov
2016-04-25 18:13         ` Dmitry Safonov [this message]
2016-04-25 19:33         ` Andy Lutomirski
2016-04-25 20:37           ` Dmitry Safonov
2016-04-25 19:20 ` [RFC 1/3] x86/signal: add SA_{X32,IA32}_ABI sa_flags Andy Lutomirski
2016-04-25 20:34   ` Dmitry Safonov
2016-04-25 20:38     ` Andy Lutomirski

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=571E5E3B.7020806@virtuozzo.com \
    --to=dsafonov@virtuozzo.com \
    --cc=0x7f454c46@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@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 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.