Re: [RFC/RFT] calloutng

From: Alexander Motin <mav_at_FreeBSD.org>
Date: Wed, 02 Jan 2013 23:39:14 +0200
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
Received on Wed Jan 02 2013 - 20:39:21 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:33 UTC