From owner-freebsd-security@FreeBSD.ORG Thu Sep 27 12:00:18 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E5E541065670 for ; Thu, 27 Sep 2012 12:00:18 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4BDA58FC0C for ; Thu, 27 Sep 2012 12:00:03 +0000 (UTC) Received: by eaac10 with SMTP id c10so667285eaa.13 for ; Thu, 27 Sep 2012 05:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=GM3ANhddSByjojXd1fucQPLh+WQsO/T84IUYeu/ufqw=; b=zA73jCnshr3Wlk2CV9HnpLWN9egupiGmjIlGshqTdAMeDZzQuwed3MoESvRDe3mmH6 xU8xOfOsMSGvqvQz3eEVvx7cCEBlOw0ObhNJZAskT44dXVXw/iRncYwKprjwm7lAJmzY crugtBn+Ih4wrMxaWzvZPIK2/x+u6uL9Jj+lkn0CrAoTlSxGw50Wef4ZJ9GBB8/CwQRN zaZFLq+GirNEFcJ+pXhWnEP0Pes4o/ro6p1CuZbU3Y50iIQkVgRoZLqcP3sqpCe5cEFJ RkPAoGZvuWD+YWa9VmiK7Tp9fjxXIU+/5l+Dj+FO3n3LDpCxsVXzs+v1qfJ1MdsxQeBJ GNCQ== Received: by 10.14.211.3 with SMTP id v3mr5492112eeo.43.1348747202376; Thu, 27 Sep 2012 05:00:02 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPS id u47sm17114012eeo.9.2012.09.27.04.59.59 (version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 05:00:00 -0700 (PDT) Date: Thu, 27 Sep 2012 12:59:56 +0100 From: RW To: freebsd-security@freebsd.org Message-ID: <20120927125956.0594fa73@gumby.homeunix.com> In-Reply-To: References: <20120918211422.GA1400@garage.freebsd.pl> <20120919192836.3a60cdfd@gumby.homeunix.com> <863923pzgi.fsf@ds4.des.no> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Collecting entropy from device_attach() times. X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 12:00:19 -0000 On Thu, 27 Sep 2012 10:56:24 +0100 Ben Laurie wrote: > On Thu, Sep 27, 2012 at 10:49 AM, Dag-Erling Sm=F8rgrav > wrote: > > RW writes: > >> "Dag-Erling Sm=F8rgrav" writes: > >> > You can't rely on the existence of a TSC. I would suggest using > >> > the fractional part of binuptime instead. > >> get_cyclecount() is supposed to be platform independent and should > >> fall-back to nanotime(9) if TSC or equivalent is absent. > > > > I just thought of another issue with get_cyclecount(). > > > > On machines with TSCs, its resolution varies with the CPU's speed > > (nominal or actual, depending on the exact model). This means that > > attachtime measurements have far lower resolution and therefore less > > entropy on slow machines than on fast ones. > > > > This doesn't mean we can't use get_cyclecount(), just that we > > shouldn't base our entropy estimates on data gathered on a fast > > system. >=20 > We should certainly see how things look on slow systems, but note that > if the resolution is lower, then the measurements will also be smaller > (assuming attachment takes similar time), and so we will claim less > entropy anyway :-) That doesn't help if the system uses binuptime(), e.g. on arm=20 static __inline uint64_t get_cyclecount(void) { struct bintime bt; binuptime(&bt); return (bt.frac ^ bt.sec); =20 } In this case it will appear to be a 18 EHz counter.