From owner-svn-src-all@FreeBSD.ORG Thu Oct 11 15:24:01 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 537D4631 for ; Thu, 11 Oct 2012 15:24:01 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 630978FC17 for ; Thu, 11 Oct 2012 15:23:59 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so1612262lag.13 for ; Thu, 11 Oct 2012 08:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4vd6n4BcpNlit11/tw6TciCNWvr7db8TVLObNR4D4k8=; b=marf6EFlhrzb/QqpGNhgbFCWa3uCa7nw44n+yvIumBb//P7R9j2HsjDvQQo0MYFSJS SmPYoTpz2vI5+DTv4oW0F1zNHqckAtFJggoKc6jl35I8NoGxW65OgACOGkIXrzz+z+cM RNUj7XT8BEVIV520NXk985uHaG5eKtbllfdcI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=4vd6n4BcpNlit11/tw6TciCNWvr7db8TVLObNR4D4k8=; b=VtSjZPUvGHqmPrS/kH1G87RLXIADPG/R9nIHH2LMbIHj8wbiNfw0iLueRQSf2/IdPa XJe6fMtEvgOAjUhdTc5ueERILUcs5vEvDwOGoFBsbX6aKVEiM6IHoT8zCtGyS2rU1iCj 5vCT/TP1unX5JZYN1QSSm1zWnO+tqRUxmOvF8s8N8icv5bXRe6mMrzn1jn+INqsT5tEB /umpSTyYUpY9CcakDZTuRRDH9/+CiSeEw5FbOnb0GkgYgZ58OJV3e/gYyHn6kDgZxj+C 3zHmGd8Gq274duAOo6jbe+Od16p+5iiNDLVQGxiaNRwOwNRaZv/KxRCwjYkFUNSq0+g3 tj0w== MIME-Version: 1.0 Received: by 10.152.47.112 with SMTP id c16mr1086244lan.50.1349969037959; Thu, 11 Oct 2012 08:23:57 -0700 (PDT) Received: by 10.112.87.106 with HTTP; Thu, 11 Oct 2012 08:23:57 -0700 (PDT) In-Reply-To: <5076C650.4040508@freebsd.org> References: <201210091425.q99EPFS6020787@svn.freebsd.org> <507451DE.9060909@freebsd.org> <977E1107-46D4-476F-A04D-AEFD87D1DE53@FreeBSD.org> <20121011114425.GA1562@garage.freebsd.pl> <5076C650.4040508@freebsd.org> Date: Thu, 11 Oct 2012 08:23:57 -0700 Message-ID: Subject: Re: svn commit: r241373 - head/lib/libc/stdlib From: Peter Wemm To: Andrey Chernov Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkZ3kxOcsDZ2B76a6lhJc26QsLf3Eor5UtSF512YCbskB6RQGaX6FDHqDQCsXt75dC8GN9S Cc: mdf@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek , svn-src-all@freebsd.org, David Chisnall , svn-src-head@freebsd.org, Eitan Adler X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 15:24:01 -0000 On Thu, Oct 11, 2012 at 6:14 AM, Andrey Chernov wrote: > On 11.10.2012 15:44, Pawel Jakub Dawidek wrote: >> On Tue, Oct 09, 2012 at 01:51:05PM -0400, Eitan Adler wrote: >>> On 9 October 2012 13:27, wrote: >>>> The original behavior can be recovered by using inline assembly to >>>> fetch the value from a register into a local C variable; this would at >>>> least not rely on undefined behavior. But I agree it's of dubious >>>> value anyways. >>> >>> I proposed this (with a patch). We want to move to not using >>> /dev/random and instead make a kernel system call directly. The patch >>> for this is not finished yet though. >> >> You should do something similar to: >> >> http://people.freebsd.org/~pjd/patches/libc_arc4random.c.patch >> > > Already half of year I told people of our serious problem with kernel's > arc4 (used here in sysctl) - it have very weak initialization at the > kernel start (only from processor clock) which is auto-fixed because of > its periodic reseeds, but only at the next reseed which happens late. I > post two patches (both working, one using atomic, another don't use it) > which reseeds kernel's arc4 as fast as we have enough real entropy. > NetBSD don't have this problem because of their different kernel's arc4 > implementation. How "late" is late? Since this was a userland patch, has it been reseeded by then? Regardless, this is getting way off topic from using an xor of an uninitialized userland variable and what the compiler optimizer might do with it. Of course that's assuming it is even a memory based stack. The sparc or ia64 register stack makes that xor even more dubious. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell