mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Indan Zupancic" <indan@nul.nu>
To: "Will Drewry" <wad@chromium.org>
Cc: "Ben Hutchings" <bhutchings@solarflare.com>,
	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, hpa@zytor.com, 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, pmoore@redhat.com,
	akpm@linux-foundation.org, corbet@lwn.net,
	eric.dumazet@gmail.com, markus@chromium.org,
	keescook@chromium.org
Subject: Re: [PATCH v10 05/11] seccomp: add system call filtering using BPF
Date: Thu, 23 Feb 2012 00:46:35 +0100	[thread overview]
Message-ID: <60d94ae06f380ff088f6270c3a536ee9.squirrel@webmail.greenhost.nl> (raw)
In-Reply-To: <CABqD9hYRPQbAY2KejstrutEO_jXU3QgBB9og_ByAaFcXZx4GHg@mail.gmail.com>

On Wed, February 22, 2012 20:47, Will Drewry wrote:
> On Wed, Feb 22, 2012 at 8:23 AM, Ben Hutchings
>> I would have thought the way to make sure the architecture is always
>> checked is to pack it together with the syscall number.

I missed that suggestion, putting the syscall number and arch in one
data field would indeed make it harder to not check the arch.

> If the current patchset used the elf machine only and not the
> AUDIT_ARCH_* that might be possible since e_machine is only 16 bits.

Using AUDIT_ARCH_ has the advantage that it contains the endianness and
width of the arch, which is crucial info for archs that support multiple
modes with the same arch. E.g. MIPS got:

#define AUDIT_ARCH_MIPS         (EM_MIPS)
#define AUDIT_ARCH_MIPSEL       (EM_MIPS|__AUDIT_ARCH_LE)
#define AUDIT_ARCH_MIPS64       (EM_MIPS|__AUDIT_ARCH_64BIT)
#define AUDIT_ARCH_MIPSEL64     (EM_MIPS|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)

So just EM_MIPS isn't enough info.

> However, that would still assume that an arch wouldn't introduce a
> syscall number above 65535 which is most likely not a safe assumption.
>  Am I wrong there?

No, it's not a safe assumption. E.g. look at arm_syscall() in
arch/arm/kernel/traps.c:

"0x9f0000 - 0x9fffff are some more esoteric system calls"

You could check if the filter read the 'arch' field and deny it if it
didn't when it returns though. Or check it in the filter check function.
Wouldn't be the nicest code ever, but it would give the same assurance
as packing it with the syscall number.

Greetings,

Indan



  reply	other threads:[~2012-02-22 23:46 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-21 17:30 [PATCH v10 01/11] sk_run_filter: add support for custom load_pointer Will Drewry
2012-02-21 17:30 ` [PATCH v10 02/11] seccomp: kill the seccomp_t typedef Will Drewry
2012-02-21 17:30 ` [PATCH v10 03/11] asm/syscall.h: add syscall_get_arch Will Drewry
2012-02-21 18:46   ` Roland McGrath
2012-02-21 18:57     ` Will Drewry
2012-02-21 19:01     ` [PATCH v11 " Will Drewry
2012-02-21 17:30 ` [PATCH v10 04/11] arch/x86: add syscall_get_arch to syscall.h Will Drewry
2012-02-21 17:30 ` [PATCH v10 05/11] seccomp: add system call filtering using BPF Will Drewry
2012-02-22  6:32   ` H. Peter Anvin
2012-02-22 19:48     ` Will Drewry
2012-02-22  8:19   ` Indan Zupancic
2012-02-22 14:23     ` Ben Hutchings
2012-02-22 19:47       ` Will Drewry
2012-02-22 23:46         ` Indan Zupancic [this message]
2012-02-22 23:51           ` Andrew Lutomirski
2012-02-23  0:08             ` Indan Zupancic
2012-02-23  1:07             ` H. Peter Anvin
2012-02-22 23:03       ` Indan Zupancic
2012-02-22 19:47     ` Will Drewry
2012-02-22 19:53       ` H. Peter Anvin
2012-02-22 20:01         ` Will Drewry
2012-02-23  0:25       ` Indan Zupancic
2012-02-21 17:30 ` [PATCH v10 06/11] seccomp: add SECCOMP_RET_ERRNO Will Drewry
2012-02-21 22:41   ` Kees Cook
2012-02-21 22:48     ` Will Drewry
2012-02-21 17:30 ` [PATCH v10 07/11] signal, x86: add SIGSYS info and make it synchronous Will Drewry
2012-02-22  8:34   ` Indan Zupancic
2012-02-22 19:48     ` Will Drewry
2012-02-22 23:38       ` Andrew Lutomirski
2012-02-22 23:53         ` Kees Cook
2012-02-23  0:05           ` Will Drewry
2012-02-23  0:08             ` Kees Cook
2012-02-23  0:29               ` H. Peter Anvin
2012-02-23  0:50                 ` Roland McGrath
2012-02-23  1:06                   ` H. Peter Anvin
2012-02-23 17:38                     ` Roland McGrath
2012-02-23 19:26                       ` Will Drewry
2012-02-23 22:15                         ` Indan Zupancic
2012-02-23 22:33                           ` Markus Gutschke
2012-02-23 22:36                             ` Will Drewry
2012-02-27 12:32                             ` Indan Zupancic
2012-02-27 16:21                               ` Will Drewry
2012-02-23 22:34                           ` [kernel-hardening] " Will Drewry
2012-02-23 16:44                 ` Will Drewry
2012-02-23  0:11         ` Roland McGrath
2012-02-21 17:30 ` [PATCH v10 08/11] seccomp: Add SECCOMP_RET_TRAP Will Drewry
2012-02-21 17:30 ` [PATCH v10 09/11] ptrace,seccomp: Add PTRACE_SECCOMP support Will Drewry
2012-02-22 12:22   ` Indan Zupancic
2012-02-22 19:47     ` [kernel-hardening] " Will Drewry
2012-02-21 17:30 ` [PATCH v10 10/11] x86: Enable HAVE_ARCH_SECCOMP_FILTER Will Drewry
2012-02-21 17:30 ` [PATCH v10 11/11] Documentation: prctl/seccomp_filter Will Drewry
2012-02-21 23:12   ` Kees Cook
2012-02-22  3:41     ` 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=60d94ae06f380ff088f6270c3a536ee9.squirrel@webmail.greenhost.nl \
    --to=indan@nul.nu \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=bhutchings@solarflare.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=djm@mindrot.org \
    --cc=eparis@redhat.com \
    --cc=eric.dumazet@gmail.com \
    --cc=hpa@zytor.com \
    --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=wad@chromium.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®