On 02.01.2013 19:09, Konstantin Belousov wrote:
On Wed, Jan 02, 2013 at 05:22:06PM +0100, Luigi Rizzo wrote:
Probably one way to close this discussion would be to provide
a sysctl so the sysadmin can decide which point in the interval
to pick when there is no suitable callout already scheduled.
Isn't trying to synchronize to the external events in this way unsafe ?
I remember, but cannot find the reference right now, a scheduler
exploit(s) which completely hide malicious thread from the time
accounting, by making it voluntary yielding right before statclock
should fire. If statistic gathering could be piggy-backed on the
external interrupt, and attacker can control the source of the external
events, wouldn't this give her a handle ?
There are many different kinds of accounting with different
characteristics. Run time for each thread calculated using high
resolution per-CPU clocks on each context switch. It is impossible to
hide from it. System load average updated using callout and aligned with
hardclock(). Hiding from it was easy before, but it can be made more
complicated (asynchronous) now. Per-CPU SYSTEM/INTERRUPT/USER/NICE/IDLE
counters are updated by statcklock(), that is asynchronous to
hardclock() and hiding from it supposed to be more complicated. But even
before it was possible, since hardclock() frequency is 8 times higher
then statclock() one. More important for scheduling fairness thread's
CPU percentage is also based on hardclock() and hiding from it was
trivial before, since all sleep primitives were strictly aligned to
hardclock(). Now it is slightly less trivial, since this alignment was
removed and user-level APIs provide no easy way to enforce it.
The only way to get really safe accounting is forget about sampling and
use potentially more expensive other ways. It was always stopped by lack
of cheap and reliable clocks. But since TSC is P-state invariant on most
of CPUs present now it could probably be reconsidered.
--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
