[185] in The Cryptographic File System users list

home help back first fref pref prev next nref lref last post

using /dev/urandom (was are there many active users...)

daemon@ATHENA.MIT.EDU (Brian Edmonds)
Wed May 24 11:29:20 2000

From owner-cfs-users@nsa.research.att.com Wed May 24 15:29:20 2000
Return-Path: <owner-cfs-users@nsa.research.att.com>
Delivered-To: cfs-mtg@CHARON2.mit.edu
Received: (qmail 13036 invoked from network); 24 May 2000 15:29:20 -0000
Received: from h-135-207-30-103.research.att.com (HELO mail-green.research.att.com) (135.207.30.103)
  by charon2.mit.edu with SMTP; 24 May 2000 15:29:20 -0000
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32])
	by mail-green.research.att.com (Postfix) with ESMTP
	id 3FF741E00A; Wed, 24 May 2000 11:29:10 -0400 (EDT)
Received: from nsa.research.att.com (majordomo@nsa.research.att.com [135.207.24.155])
	by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id LAA19686;
	Wed, 24 May 2000 11:28:59 -0400 (EDT)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id LAA18992 for cfs-users-list; Wed, 24 May 2000 11:25:57 -0400 (EDT)
X-Authentication-Warning: nsa.research.att.com: majordomo set sender to owner-cfs-users@nsa.research.att.com using -f
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id LAA18988 for <cfs-users@nsa.research.att.com>; Wed, 24 May 2000 11:25:55 -0400 (EDT)
Received: by mail-blue.research.att.com (Postfix)
	id E7DC74CE16; Wed, 24 May 2000 11:28:27 -0400 (EDT)
Delivered-To: cfs-users@research.att.com
Received: from lios.gweep.bc.ca (a3a17164.sympatico.bconnected.net [209.53.11.73])
	by mail-blue.research.att.com (Postfix) with ESMTP id 4BD3D4CE04
	for <cfs-users@research.att.com>; Wed, 24 May 2000 11:28:27 -0400 (EDT)
Received: (from uucp@localhost)
	by lios.gweep.bc.ca (8.9.3/8.9.1) with UUCP id IAA12957
	for cfs-users@research.att.com; Wed, 24 May 2000 08:28:26 -0700
Received: by yuri.gweep.bc.ca (Postfix, from userid 500)
	id 3709856B3B; Wed, 24 May 2000 08:18:37 -0700 (PDT)
To: cfs-users@research.att.com
Subject: using /dev/urandom (was are there many active users...)
References: <m3wvklxpxu.fsf@yuri.gweep.bc.ca>
	<20000524093619.A40679@caerdonn.eurocontrol.fr>
From: Brian Edmonds <brian@gweep.bc.ca>
Date: 24 May 2000 08:18:36 -0700
In-Reply-To: Ollivier Robert's message of "Wed, 24 May 2000 09:36:19 +0200"
Message-ID: <m3aehgf037.fsf_-_@yuri.gweep.bc.ca>
Lines: 44
User-Agent: Gnus/5.0806 (Gnus v5.8.6) XEmacs/21.1 (Bryce Canyon)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-cfs-users@research.att.com
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ollivier Robert <roberto@eurocontrol.fr> writes:
> And Linux specific (like far too many free software projects these
> days).

It's unfortunate, but when you're making a new filesystem, if you want
to get the best performance that usually means kernel development, and
that usually means OS specific.  CFS is cool in that it's very portable,
and I've always wondered why there weren't more cool NFS hacks, but it
does burn cycles to achieve it.  Which given processor speeds these days
may be a reasonable design decision, but that's a different discussion.

> Have you looked at why it loops ? Could you post here your patch for
> using /dev/urandom ? The various *BSD have it too so I'm interested.

I attached to a looping process with gdb, and it was stuck waiting for
an itimer alarm that apparently never came.  I didn't feel up to
debugging code that was rather obscure to me (I'm not a cryptographer
and make no claims of understanding randomness), so I just removed the
bulk of the code in the module and replaced the low level randomness
function with a simple one that reads from /dev/urandom[1].

Thus I don't really have a patch, sorry; it was a quick hack to make
things work for me.  If there is serious interest in this I could go
back and redo it in a more standard manner so I could produce a real
patch, but if Matt's planning a 2.0 release RSN, as I've been told by
many people since my post, it may not be worth the trouble.

Brian.

[1] I realize this may not generate as good a randomness as /dev/random,
but it was an easy hack, and almost certainly good enough for my basic
needs.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>

iD8DBQE5K/JxcCEFQUX5+OwRAm8XAKDk7dH1jmH1+dhgTQflUKPbO61Q1gCdFWcI
PNsXlKqgVX8Nl0PZGx9B5LU=
=6igz
-----END PGP SIGNATURE-----


home help back first fref pref prev next nref lref last post