From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4C39D21F185 for ; Mon, 9 Sep 2013 08:17:02 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id xa7so6236426pbc.31 for ; Mon, 09 Sep 2013 08:17:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=FbbLFKQgE/QxFWyPLrcElorOmCb+iHfwn4ObWXqlHVE=; b=kP1dbmObuRp9aikM5Hh7xuJyqdpW/eyUqSRy0ZhO9VQmSnW0WSzkkzqzNI19bnt5Xq NNB+wEKfyRlxwIOoE6WLe44tW4tDt3RGg1QcfPyWivRB6j31VBBVt4JVn1/qB1G2C6Jv Su1JqV3Y0BNRx38yq7KCEv0u9naPFjFPGWiBPs0wVzG3ByAhPRbWykyHNNXP8t8Ul81s i0zaQs3wRNK7xGiPYuszGTcyWr5Q0Vn5UVcRp847fYp7u64wEwGKtxua82lEqQYAO8DJ B1ksGkbkMo+TE1kbIvzhN5MPr/nXX35X5/Th/j+v9pLZF0CpRQfbLBIP4QalhkVx0vT9 J2Jw== X-Gm-Message-State: ALoCoQk0tZHgAhOe/mEzMVnw4mdD+XgbamK4ViXTvRhuO++UCQFv27j3mgFpy7NMjmQ6XN4XewUn X-Received: by 10.66.141.165 with SMTP id rp5mr14234681pab.90.1378739812614; Mon, 09 Sep 2013 08:16:52 -0700 (PDT) Received: from nehalam.linuxnetplumber.net (static-50-53-69-237.bvtn.or.frontiernet.net. [50.53.69.237]) by mx.google.com with ESMTPSA id in2sm16823841pbc.37.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 09 Sep 2013 08:16:52 -0700 (PDT) Date: Mon, 9 Sep 2013 08:16:45 -0700 From: Stephen Hemminger To: Dave Taht Message-ID: <20130909081645.03610591@nehalam.linuxnetplumber.net> In-Reply-To: <20130908190427.GA14461@lists.bufferbloat.net> References: <20130908190427.GA14461@lists.bufferbloat.net> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: openwrt-devel@lists.openwrt.org, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] getting more randomness by improving MIPS get_cycles() X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 15:17:02 -0000 On Sun, 8 Sep 2013 12:04:27 -0700 Dave Taht wrote: > In light of the whole nsa hoo-ra (stuff like this) > > https://plus.google.com/u/0/117091380454742934025/posts/SDcoemc9V3J > > Ted Tso has pointed out to me that apparently mips' does not have a working > generic get_cycles() call, but instead returns 0 in all cases. > > e.g: In arch/mips/include/asm/timex.h: > > typedef unsigned int cycles_t; > > static inline cycles_t get_cycles(void) > { > return 0; > } > > Um..... > > get_cycles() is used in innumerable places in random.c. > > This is double plus ungood... I am REALLY hoping I'm merely misreading > the code... > > An example: > > (see drivers/char/random.c for how often it is used) > > /* > * Add device- or boot-specific data to the input and nonblocking > * pools to help initialize them to unique values. > * > * None of this adds any entropy, it is meant to avoid the > * problem of the nonblocking pool having similar initial state > * across largely identical devices. > */ > > void add_device_randomness(const void *buf, unsigned int size) > { > unsigned long time = get_cycles() ^ jiffies; > > ... > > So, what blocks having a working get_cycles in common mips architectures? In order to implement get_cycles() a high resolution hardware counter with quick access is necessary.