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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [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]
  Powered by Linux