Re: [patch] vsyscall feature

From: Andrea Arcangeli (andrea@suse.de)
Date: Wed Mar 08 2000 - 13:28:48 EST


On 8 Mar 2000, Mike Coleman wrote:

>Think about the Pentium cpu serial number id (whatever it was called). If
>userland code has direct access to this number, or can enable direct access
>without hitting the kernel, you've got a big problem.

The whole point is that userspace has not direct access to _anything_. See
my plan below.

What we have to provide to userspace is a table of pointer to functions,
the vsyscall table. Then glibc is changed to use:

        call *0xfffc000

to call gettimeofday and:

        call *0xffffc004

to call getpid (instead of the INT 0x80)

etc for all the other possible vsyscalls.

The kernel has to setup the tables so that they point to other readable
pages in kernel space filled with the userspace code that the kernel want
to run and filled with the data information that the kernel wants to show
to userspace.

So the data information won't be at a known location and even if userspace
disasseble the vsyscalls to find where the information is placed to read
it without passing thorugh the vsyscall table, userspace still will read
what we want to show (in your example you can show the cpuid that you
prefer).

For ptrace we can let userspace to trivially check a bitflag that we
set/clear at ptrace start/stop time, and if the bitflag is set we let the
vsyscall to recall the real syscall to make ptrace to work also with all
the vsyscall cleanly.

Then with a new syscall we can also dynamically overwrite all the vsyscall
table to make it to point to a secondary version of the vsyscalls that
will redirect _all_ the vsyscalls to the real syscalls with minimal
overhead. Then this new syscall will make not readable the real vsyscalls
implementation and data. So that you can switch vsyscall on and off with
maximal flexibility and you'll still be able to fooling a precise
current->comm with your own xtime.

Andrea

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:14 EST