From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 21:39:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2006AA95; Wed, 2 Jan 2013 21:39:21 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by mx1.freebsd.org (Postfix) with ESMTP id 614D7623; Wed, 2 Jan 2013 21:39:20 +0000 (UTC) Received: by mail-ea0-f178.google.com with SMTP id k11so6115397eaa.37 for ; Wed, 02 Jan 2013 13:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Uo48LHfkJdD9FVWjrQOe4d6qpXXXfB1b+Md8xaa4JYg=; b=VCkGVKddQebRYa8Q1TsRe+UT1A7G4zqhQ5qE35Vl9FSrEYf3vuE0unLy0IDdMTVBcG neVE6n/PQOcvLFXPLDj07I9hsWv8lWOBq93PpRsG3d4XQjchEwSEPnafb6EJJt7vmUy3 AAViJ5qAHFBQXogJVkfMc4pk9uxwV//T3vJZQLdnqzHKs4d33w1LC7sGBl9NSA+CQVr+ fdrveDjF6t6PdJCwEPaUhBrSEzLpcatPTf3McPzGQ2r0L4bHiqnciDi6Wcv5WjnWrNPn 6S47+OLdrd2gVT++CtmLncq3JDNJsPvaYOsBXkTGLnVf/8fVRLJBtz5piVmVHxpZFW3+ bJdQ== X-Received: by 10.14.204.70 with SMTP id g46mr102666330eeo.15.1357162759189; Wed, 02 Jan 2013 13:39:19 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id l3sm100090480eem.14.2013.01.02.13.39.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Jan 2013 13:39:17 -0800 (PST) Sender: Alexander Motin Message-ID: <50E4A902.4050307@FreeBSD.org> Date: Wed, 02 Jan 2013 23:39:14 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: [RFC/RFT] calloutng 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> <20130102162206.GA45701@onelab2.iet.unipi.it> <20130102170934.GA82219@kib.kiev.ua> In-Reply-To: <20130102170934.GA82219@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Ian Lepore , freebsd-arch@freebsd.org, FreeBSD Current , Marius Strobl , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 21:39:21 -0000 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