public inbox for linux-m68k@lists.linux-m68k.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Andreas Schwab <schwab@linux-m68k.org>,
	Greg Ungerer <gerg@snapgear.com>,
	Gavin Lambert <gavinl@compacsort.com>,
	uClinux development list <uclinux-dev@uclinux.org>,
	Philippe De Muyter <phdm@macqel.be>,
	Linux/m68k <linux-m68k@lists.linux-m68k.org>,
	linux-arch@vger.kernel.org
Subject: Re: Writable sys_call_table (was: Re: [uClinux-dev] [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table)
Date: Mon, 18 Apr 2011 16:49:31 +0200	[thread overview]
Message-ID: <201104181649.31492.arnd@arndb.de> (raw)
In-Reply-To: <BANLkTimbHgmUvisE7+TCkgthejNi_zdojQ@mail.gmail.com>

On Wednesday 13 April 2011, Geert Uytterhoeven wrote:
> On Thu, Apr 7, 2011 at 10:29, Andreas Schwab <schwab@linux-m68k.org> wrote:
> > Geert Uytterhoeven <geert@linux-m68k.org> writes:
> >> Isn't there a reason it was read-write on m68k, like the table may be changed
> >> at runtime (to install rootkits :-)? Have to check what the other arches do...
> >
> > Initially the syscall_table in Linux has always been writable, bb152f53
> > ("x86/x86_64: mark rodata section read-only: make some datastructures
> > const") made it read-only on x86.  Apparently nobody bothered to do the
> > equivalent change on m68k (I don't think anything makes the kernel text
> > segment write protected anyway).
> 
> 11 arches still store it in "data", including the 4 using the new
> asm-generic/unistd.h
> framework. 9 use "rodata" and 6 use "text".
> The constness of C "extern" declarations doesn't necessarily matches the
> actual sections.
> 

Thanks for pointing this out. Should we apply this patch?
---
[PATCH] mark sys_call_table as const

There is no reason to have sys_call_table writable, and putting
it into the rodata section can make it harder for malicious users
to overwrite the entry points.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/arch/score/kernel/sys_call_table.c b/arch/score/kernel/sys_call_table.c
index 287369b..7be73dc 100644
--- a/arch/score/kernel/sys_call_table.c
+++ b/arch/score/kernel/sys_call_table.c
@@ -7,6 +7,6 @@
 #undef __SYSCALL
 #define __SYSCALL(nr, call) [nr] = (call),
 
-void *sys_call_table[__NR_syscalls] = {
+const void *sys_call_table[__NR_syscalls] = {
 #include <asm/unistd.h>
 };
diff --git a/arch/tile/kernel/sys.c b/arch/tile/kernel/sys.c
index e2187d2..3f2ba14 100644
--- a/arch/tile/kernel/sys.c
+++ b/arch/tile/kernel/sys.c
@@ -122,7 +122,7 @@ SYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned long, len,
  * Note that we can't include <linux/unistd.h> here since the header
  * guard will defeat us; <asm/unistd.h> checks for __SYSCALL as well.
  */
-void *sys_call_table[__NR_syscalls] = {
+const void *sys_call_table[__NR_syscalls] = {
 	[0 ... __NR_syscalls-1] = sys_ni_syscall,
 #include <asm/unistd.h>
 };
diff --git a/arch/tile/kernel/compat.c b/arch/tile/kernel/compat.c
index dbc213a..d221452 100644
--- a/arch/tile/kernel/compat.c
+++ b/arch/tile/kernel/compat.c
@@ -166,7 +166,7 @@ long tile_compat_sys_msgrcv(int msqid,
  * Note that we can't include <linux/unistd.h> here since the header
  * guard will defeat us; <asm/unistd.h> checks for __SYSCALL as well.
  */
-void *compat_sys_call_table[__NR_syscalls] = {
+const void *compat_sys_call_table[__NR_syscalls] = {
 	[0 ... __NR_syscalls-1] = sys_ni_syscall,
 #include <asm/unistd.h>
 };
diff --git a/arch/unicore32/kernel/sys.c b/arch/unicore32/kernel/sys.c
index 3afe60a..7a16c7e 100644
--- a/arch/unicore32/kernel/sys.c
+++ b/arch/unicore32/kernel/sys.c
@@ -120,7 +120,7 @@ SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
 #define __SYSCALL(nr, call)	[nr] = (call),
 
 /* Note that we don't include <linux/unistd.h> but <asm/unistd.h> */
-void *sys_call_table[__NR_syscalls] = {
+const void *sys_call_table[__NR_syscalls] = {
 	[0 ... __NR_syscalls-1] = sys_ni_syscall,
 #include <asm/unistd.h>
 };

       reply	other threads:[~2011-04-18 14:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <BANLkTimbHgmUvisE7+TCkgthejNi_zdojQ@mail.gmail.com>
2011-04-18 14:49 ` Arnd Bergmann [this message]
2011-04-18 16:21   ` Writable sys_call_table (was: Re: [uClinux-dev] [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table) Andreas Schwab
2011-04-19  7:48     ` Arnd Bergmann
2011-04-19  8:12       ` Finn Thain
2011-04-19 11:54         ` Andreas Schwab
     [not found]         ` <m2k4eqfocu.fsf@igel.home>
2011-04-19 12:16           ` Arnd Bergmann
2011-04-19 13:25             ` Andreas Schwab
2011-04-19 15:31           ` Finn Thain
2011-04-13 18:05 Geert Uytterhoeven

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=201104181649.31492.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=gavinl@compacsort.com \
    --cc=geert@linux-m68k.org \
    --cc=gerg@snapgear.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=phdm@macqel.be \
    --cc=schwab@linux-m68k.org \
    --cc=uclinux-dev@uclinux.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