All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Drewry <wad@chromium.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-doc@vger.kernel.org, kernel-hardening@lists.openwall.com,
	netdev@vger.kernel.org, x86@kernel.org, arnd@arndb.de,
	davem@davemloft.net, mingo@redhat.com, oleg@redhat.com,
	peterz@infradead.org, rdunlap@xenotime.net,
	mcgrathr@chromium.org, tglx@linutronix.de, luto@mit.edu,
	eparis@redhat.com, serge.hallyn@canonical.com, djm@mindrot.org,
	scarybeasts@gmail.com, indan@nul.nu, pmoore@redhat.com,
	akpm@linux-foundation.org, corbet@lwn.net,
	eric.dumazet@gmail.com, markus@chromium.org,
	coreyb@linux.vnet.ibm.com, keescook@chromium.org
Subject: Re: [PATCH v15 04/13] arch/x86: add syscall_get_arch to syscall.h
Date: Wed, 11 Apr 2012 10:41:24 -0500	[thread overview]
Message-ID: <CABqD9haw2YutkSQHO0Qq19eveqwKCEi=L3fpCYupqvakW3jDMw@mail.gmail.com> (raw)
In-Reply-To: <4F84F895.4080101@zytor.com>

On Tue, Apr 10, 2012 at 10:20 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 04/10/2012 08:13 PM, Will Drewry wrote:
>> On Sun, Mar 25, 2012 at 2:34 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> On 03/14/2012 08:11 PM, Will Drewry wrote:
>>>>
>>>> +static inline int syscall_get_arch(struct task_struct *task,
>>>> +                                struct pt_regs *regs)
>>>> +{
>>>> +#ifdef CONFIG_IA32_EMULATION
>>>> +     /*
>>>> +      * TS_COMPAT is set for 32-bit syscall entries and then
>>>> +      * remains set until we return to user mode.
>>>> +      *
>>>> +      * TIF_IA32 tasks should always have TS_COMPAT set at
>>>> +      * system call time.
>>>> +      */
>>>> +     if (task_thread_info(task)->status & TS_COMPAT)
>>>> +             return AUDIT_ARCH_I386;
>>>> +#endif
>>>> +     return AUDIT_ARCH_X86_64;
>>>> +}
>>>>  #endif       /* CONFIG_X86_32 */
>>>>
>>>>  #endif       /* _ASM_X86_SYSCALL_H */
>>>
>>> Just one FYI on this: after the x32 changes are upstream this can be
>>> implemented in terms of is_ia32_task().
>>
>> Now that I've seen is_ia32_task(), it appears to be exactly the same as above:
>> (1)  If we're x86_32, it's ia32
>> (2)  If we're x86_64, ia32 == !!(status & TS_COMPAT)
>> (3)  Otherwise, it's x86_64, including x32
>>
>> Am I missing something? Should is_ia32_task(void) take a task_struct?
>> Right now, I don't see any reason to change the code, as posted, but
>> maybe I am mis-reading?
>>
>
> Sorry, answered the wrong question.  Yes, it is the same as above...
> just wandered if we could centralize this test.  It might indeed make
> sense to provide general predicates which take a task pointer.

Makes sense to me. I'm leaving this specific patch alone at present.

That said, a quick grep shows only  a handful of ia32 references:
./arch/x86/include/asm/compat.h:        return is_ia32_task() || is_x32_task();
./arch/x86/ia32/ia32_signal.c:  bool ia32 = is_ia32_task();
./arch/x86/kernel/ptrace.c:     if (!is_ia32_task())

Would it make sense to make a new predicate or just expand the one
added in 3.4 to take a task_struct parameter? I'm not sure if there'd
be much fallout in converting these from directly checking
current_thread_info to task_thread_info.

It's a small patch either way.

cheers!
will

WARNING: multiple messages have this Message-ID (diff)
From: Will Drewry <wad@chromium.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-doc@vger.kernel.org, kernel-hardening@lists.openwall.com,
	netdev@vger.kernel.org, x86@kernel.org, arnd@arndb.de,
	davem@davemloft.net, mingo@redhat.com, oleg@redhat.com,
	peterz@infradead.org, rdunlap@xenotime.net,
	mcgrathr@chromium.org, tglx@linutronix.de, luto@mit.edu,
	eparis@redhat.com, serge.hallyn@canonical.com, djm@mindrot.org,
	scarybeasts@gmail.com, indan@nul.nu, pmoore@redhat.com,
	akpm@linux-foundation.org, corbet@lwn.net,
	eric.dumazet@gmail.com, markus@chromium.org,
	coreyb@linux.vnet.ibm.com, keescook@chromium.org
Subject: [kernel-hardening] Re: [PATCH v15 04/13] arch/x86: add syscall_get_arch to syscall.h
Date: Wed, 11 Apr 2012 10:41:24 -0500	[thread overview]
Message-ID: <CABqD9haw2YutkSQHO0Qq19eveqwKCEi=L3fpCYupqvakW3jDMw@mail.gmail.com> (raw)
In-Reply-To: <4F84F895.4080101@zytor.com>

On Tue, Apr 10, 2012 at 10:20 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 04/10/2012 08:13 PM, Will Drewry wrote:
>> On Sun, Mar 25, 2012 at 2:34 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> On 03/14/2012 08:11 PM, Will Drewry wrote:
>>>>
>>>> +static inline int syscall_get_arch(struct task_struct *task,
>>>> +                                struct pt_regs *regs)
>>>> +{
>>>> +#ifdef CONFIG_IA32_EMULATION
>>>> +     /*
>>>> +      * TS_COMPAT is set for 32-bit syscall entries and then
>>>> +      * remains set until we return to user mode.
>>>> +      *
>>>> +      * TIF_IA32 tasks should always have TS_COMPAT set at
>>>> +      * system call time.
>>>> +      */
>>>> +     if (task_thread_info(task)->status & TS_COMPAT)
>>>> +             return AUDIT_ARCH_I386;
>>>> +#endif
>>>> +     return AUDIT_ARCH_X86_64;
>>>> +}
>>>>  #endif       /* CONFIG_X86_32 */
>>>>
>>>>  #endif       /* _ASM_X86_SYSCALL_H */
>>>
>>> Just one FYI on this: after the x32 changes are upstream this can be
>>> implemented in terms of is_ia32_task().
>>
>> Now that I've seen is_ia32_task(), it appears to be exactly the same as above:
>> (1)  If we're x86_32, it's ia32
>> (2)  If we're x86_64, ia32 == !!(status & TS_COMPAT)
>> (3)  Otherwise, it's x86_64, including x32
>>
>> Am I missing something? Should is_ia32_task(void) take a task_struct?
>> Right now, I don't see any reason to change the code, as posted, but
>> maybe I am mis-reading?
>>
>
> Sorry, answered the wrong question.  Yes, it is the same as above...
> just wandered if we could centralize this test.  It might indeed make
> sense to provide general predicates which take a task pointer.

Makes sense to me. I'm leaving this specific patch alone at present.

That said, a quick grep shows only  a handful of ia32 references:
./arch/x86/include/asm/compat.h:        return is_ia32_task() || is_x32_task();
./arch/x86/ia32/ia32_signal.c:  bool ia32 = is_ia32_task();
./arch/x86/kernel/ptrace.c:     if (!is_ia32_task())

Would it make sense to make a new predicate or just expand the one
added in 3.4 to take a task_struct parameter? I'm not sure if there'd
be much fallout in converting these from directly checking
current_thread_info to task_thread_info.

It's a small patch either way.

cheers!
will

  reply	other threads:[~2012-04-11 15:41 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-15  3:11 [PATCH v15 00/13] seccomp_filter: syscall filtering using BPF Will Drewry
2012-03-15  3:11 ` [kernel-hardening] " Will Drewry
2012-03-15  3:11 ` [PATCH v15 01/13] sk_run_filter: add BPF_S_ANC_SECCOMP_LD_W Will Drewry
2012-03-15  3:11   ` [kernel-hardening] " Will Drewry
2012-03-16 18:15   ` Eric Dumazet
2012-03-16 18:15     ` [kernel-hardening] " Eric Dumazet
2012-03-15  3:11 ` [PATCH v15 02/13] net/compat.c,linux/filter.h: share compat_sock_fprog Will Drewry
2012-03-15  3:11   ` [kernel-hardening] " Will Drewry
2012-03-16 18:16   ` Eric Dumazet
2012-03-16 18:16     ` [kernel-hardening] " Eric Dumazet
2012-03-16 19:23     ` Will Drewry
2012-03-16 19:23       ` [kernel-hardening] " Will Drewry
2012-03-15  3:11 ` [PATCH v15 03/13] seccomp: kill the seccomp_t typedef Will Drewry
2012-03-15  3:11   ` [kernel-hardening] " Will Drewry
2012-03-15  3:11 ` [PATCH v15 04/13] arch/x86: add syscall_get_arch to syscall.h Will Drewry
2012-03-15  3:11   ` [kernel-hardening] " Will Drewry
2012-03-25 19:34   ` H. Peter Anvin
2012-03-25 19:34     ` [kernel-hardening] " H. Peter Anvin
2012-04-11  3:13     ` Will Drewry
2012-04-11  3:13       ` [kernel-hardening] " Will Drewry
2012-04-11  3:16       ` H. Peter Anvin
2012-04-11  3:16         ` [kernel-hardening] " H. Peter Anvin
2012-04-11  3:20       ` H. Peter Anvin
2012-04-11  3:20         ` [kernel-hardening] " H. Peter Anvin
2012-04-11 15:41         ` Will Drewry [this message]
2012-04-11 15:41           ` Will Drewry
2012-03-15  3:11 ` [PATCH v15 05/13] asm/syscall.h: add syscall_get_arch Will Drewry
2012-03-15  3:11   ` [kernel-hardening] " Will Drewry
2012-03-15  3:11 ` [PATCH v15 06/13] seccomp: add system call filtering using BPF Will Drewry
2012-03-15  3:11   ` [kernel-hardening] " Will Drewry
2012-03-25  7:31   ` Vladimir Murzin
2012-03-25  7:31     ` [kernel-hardening] " Vladimir Murzin
2012-03-15  3:11 ` [PATCH v15 07/13] seccomp: remove duplicated failure logging Will Drewry
2012-03-15  3:11   ` [kernel-hardening] " Will Drewry
2012-03-15  3:12 ` [PATCH v15 08/13] seccomp: add SECCOMP_RET_ERRNO Will Drewry
2012-03-15  3:12   ` [kernel-hardening] " Will Drewry
2012-03-15  3:12 ` [PATCH v15 09/13] signal, x86: add SIGSYS info and make it synchronous Will Drewry
2012-03-15  3:12   ` [kernel-hardening] " Will Drewry
2012-03-15  3:12 ` [PATCH v15 10/13] seccomp: Add SECCOMP_RET_TRAP Will Drewry
2012-03-15  3:12   ` [kernel-hardening] " Will Drewry
2012-03-15  3:12 ` [PATCH v15 11/13] ptrace,seccomp: Add PTRACE_SECCOMP support Will Drewry
2012-03-15  3:12   ` [kernel-hardening] " Will Drewry
2012-03-15  4:49   ` Indan Zupancic
2012-03-15  4:49     ` [kernel-hardening] " Indan Zupancic
2012-03-15  4:49     ` Indan Zupancic
2012-03-15  4:49     ` Indan Zupancic
2012-03-15 14:40     ` Will Drewry
2012-03-15 14:40       ` [kernel-hardening] " Will Drewry
2012-03-15  3:12 ` [PATCH v15 12/13] x86: Enable HAVE_ARCH_SECCOMP_FILTER Will Drewry
2012-03-15  3:12   ` [kernel-hardening] " Will Drewry
2012-03-15  3:12 ` [PATCH v15 13/13] Documentation: prctl/seccomp_filter Will Drewry
2012-03-15  3:12   ` [kernel-hardening] " Will Drewry
2012-03-25 19:36 ` [PATCH v15 00/13] seccomp_filter: syscall filtering using BPF H. Peter Anvin
2012-03-25 19:36   ` [kernel-hardening] " H. Peter Anvin
2012-03-26 16:53   ` Will Drewry
2012-03-26 16:53     ` [kernel-hardening] " Will Drewry

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='CABqD9haw2YutkSQHO0Qq19eveqwKCEi=L3fpCYupqvakW3jDMw@mail.gmail.com' \
    --to=wad@chromium.org \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=corbet@lwn.net \
    --cc=coreyb@linux.vnet.ibm.com \
    --cc=davem@davemloft.net \
    --cc=djm@mindrot.org \
    --cc=eparis@redhat.com \
    --cc=eric.dumazet@gmail.com \
    --cc=hpa@zytor.com \
    --cc=indan@nul.nu \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@mit.edu \
    --cc=markus@chromium.org \
    --cc=mcgrathr@chromium.org \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pmoore@redhat.com \
    --cc=rdunlap@xenotime.net \
    --cc=scarybeasts@gmail.com \
    --cc=serge.hallyn@canonical.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.