Re: [PATCH] Read only syscall tables for x86_64 and i386

["Richard B. Johnson" <linux-os@analogic.com>]

On Fri, 1 Jul 2005, Christoph Lameter wrote:

> On Wed, 29 Jun 2005, Andi Kleen wrote:
>
> > On Tue, Jun 28, 2005 at 12:41:59PM -0700, Christoph Lameter wrote:
> > > On Tue, 28 Jun 2005, Andi Kleen wrote:
> > >
> > > > It's unfortunately useless because all the kernel is mapped in the
> > > > same 2 or 4MB page has to be writable because it overlaps with real
> > > > direct mapped memory.
> > >
> > > The question is: Are syscall tables are supposed to be
> > > writable? If no then this patch should go in. If yes then forget about it.
> >
> > 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?
>
> > 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???
>
> > > 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.
>
> The issue is correct placement of variables. Read only variables are
> placed in a different section and the syscall tables are read only and
> need to be place in the correct section.

I modified my sycall table to put it in ".section .rodata". It appears
as though read-only is not enforced in the kernel. I don't know
why because, at least with ix86, both data and code can be made read-
only.

You just write to it with a segment descriptor that allows R/W, then
use another for R/O.  It is true that kernel code can create any
segment descriptor it wants, dynamically, thus a properly-written
program can ultimately write to what was once R/O data. However,
I think it should default to R/O which should cut down on the
number of cheap hacks that can damage it.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
                 98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/