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

Andi Kleen
2005-07-01T20:31:00Z

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