Date: Wed, 02 Jan 2013 23:39:14 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Davide Italiano <davide@freebsd.org>, Ian Lepore <freebsd@damnhippie.dyndns.org>, freebsd-arch@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>, Marius Strobl <marius@alchemy.franken.de>, Luigi Rizzo <rizzo@iet.unipi.it> Subject: Re: [RFC/RFT] calloutng Message-ID: <50E4A902.4050307@FreeBSD.org> In-Reply-To: <20130102170934.GA82219@kib.kiev.ua> References: <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> <CAO4K=PUHAH=UNzMde0V2TwkN5vj3gw9hHj5yCQxDvdUn%2Buqv7w@mail.gmail.com> <20130102162206.GA45701@onelab2.iet.unipi.it> <20130102170934.GA82219@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50E4A902.4050307>