From: Andi Kleen <ak@suse.de>
To: Christoph Lameter <christoph@lameter.com>
Cc: Andi Kleen <ak@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Read only syscall tables for x86_64 and i386
Date: Fri, 1 Jul 2005 22:28:06 +0200 [thread overview]
Message-ID: <20050701202805.GF21330@wotan.suse.de> (raw)
In-Reply-To: <Pine.LNX.4.62.0507011302090.19234@graphe.net>
On Fri, Jul 01, 2005 at 01:10:12PM -0700, Christoph Lameter wrote:
> > I think it would make sense in theory to write protect them
> > together with the kernel code and the modules
> > (just to make root kit writing slightly harder)
>
> Seems that you are evading the question that I asked. Are syscall tables
> supposed to be writable?
I did answer it. But again: yes I think it makes sense in theory
to make them read only.
Just we cannot do it right now on i386/x86-64 due to the reasons I lined out
in my previous mail.
>
> > BTW the kernel actually needs to write to code once
> > to apply alternative(), but it would't be a problem to use
> > a temporary mapping for this.
>
> What does this have to do with the syscall table???
It is directly related to writable .text.
>
> > > The ability to protect a readonly section may be another issue.
> >
> > Well, it's the overriding issue here. Just pretending it's readonly
> > when it isn't doesn't seem useful.
>
> This is all are off-topic talking about a different issue. And we are
> already "pretending" that lots of other stuff in the readonly section is
> readonly.
Putting it into a "ro section" when it isn't actually read only is completely
useless and does not do anything useful. So unless you figure out
a way to make a true ro section without performance penalty I wouldn't bother.
If you really want it for cosmetic reasons you can still do it,
but it is about at the same usefullness level as shuffling white space in
the source around.
-Andi
next prev parent reply other threads:[~2005-07-01 20:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.62.0506281141050.959@graphe.net.suse.lists.linux.kernel>
2005-06-28 19:33 ` [PATCH] Read only syscall tables for x86_64 and i386 Andi Kleen
2005-06-28 19:41 ` Christoph Lameter
2005-06-29 0:06 ` Arnd Bergmann
2005-06-29 2:49 ` Andi Kleen
2005-07-01 20:10 ` Christoph Lameter
2005-07-01 20:28 ` Andi Kleen [this message]
2005-07-01 20:47 ` Richard B. Johnson
2005-07-01 21:13 ` Alan Cox
2005-07-01 20:34 ` Richard B. Johnson
2005-06-28 18:47 Christoph Lameter
2005-06-28 18:56 ` Arjan van de Ven
2005-06-28 19:26 ` Christoph Lameter
2005-06-28 19:41 ` Christoph Hellwig
[not found] ` <87oe9q70no.fsf@jbms.ath.cx>
[not found] ` <Pine.LNX.4.62.0506281218030.1454@graphe.net>
2005-06-28 19:27 ` Jeremy Maitin-Shepard
2005-06-28 19:31 ` Christoph Lameter
2005-06-28 19:41 ` Jeremy Maitin-Shepard
2005-06-28 19:42 ` Christoph Hellwig
2005-06-28 19:52 ` Jeremy Maitin-Shepard
2005-06-28 20:11 ` Arjan van de Ven
2005-06-28 20:23 ` Jeremy Maitin-Shepard
2005-06-28 19:47 ` Arjan van de Ven
2005-06-28 20:00 ` Jeremy Maitin-Shepard
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=20050701202805.GF21330@wotan.suse.de \
--to=ak@suse.de \
--cc=christoph@lameter.com \
--cc=linux-kernel@vger.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.