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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|