lkml.org 
[lkml]   [2000]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch] vsyscall feature
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.112 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site