Messages in this thread | | | Subject | Re: [patch] vsyscall feature | From | Mike Coleman <> | Date | 08 Mar 2000 17:07:43 -0600 |
| |
Artur Skawina <skawina@geocities.com> writes: > i'd like to avoid this kind of special cases, they all have a cost. > We're talking about feeding a hostile process bogus data and the process > attempting counter measures -- (hopefully) a very rare scenario in RL. > So the cost does not seem to justified, simply turning off the > usermode-syscalls and unmapping the data globally should be ok. > (this is kind of what i'd like to do for ptrace anyway) > That way only a system that needs this feature has to pay the price. > [there might be a better solution, but i need to do some benchmarking > first]
This seems reasonable to me. The key thing is that the controller can easily arrange that controlled (ptraced) processes cannot get at any usable info from these special pages.
> > Well, if it's possible in user space, we leave it to the author of that > > tricky sandbox program to solve the details :-) > > hmm, i can't see a way to do this 100% transparently, not w/o further > restrictions (turning off rdtsc, artifically reducing/altering timings etc).
This would be nice, but I do have doubts as to whether it's really possible. Since there are currently 100 other ways a rogue can discover that it's being followed, it doesn't seem right to seriously bend the vsyscall design for this reason.
--Mike
- 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/
| |