From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by huchra.bufferbloat.net (Postfix, from userid 1000) id EEA312021DD; Sun, 8 Sep 2013 12:04:27 -0700 (PDT) Date: Sun, 8 Sep 2013 12:04:27 -0700 From: Dave Taht To: openwrt-devel@lists.openwrt.org, cerowrt-devel@lists.bufferbloat.net Message-ID: <20130908190427.GA14461@lists.bufferbloat.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [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: Sun, 08 Sep 2013 19:04:28 -0000 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?