From owner-svn-src-head@FreeBSD.ORG Thu Oct 11 15:24:00 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66F7E629 for ; Thu, 11 Oct 2012 15:24:00 +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 CB5A48FC0A for ; Thu, 11 Oct 2012 15:23:59 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so1612264lag.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=nH2uxRo0FCmYaKunLi2oNWtJcY4PAFqf7ehWEGmdP22Xs3wRIpKLInBkXY8Rdfq81I qZUu5CPHzbnOOOgjJq1rvuVaSwbKnqoz9dUwJ9RLVgIKxYKI5glDdPp0yz1Oyi3I7Awd FGsTgFqsYy2jgX1VON48R/Xz3wzDXcWkPI3nrXsCNZ+kZ+c0uC/+Y9ISqlELLy7Oyc9d vnNpADWET7IlFIO4KyP2DbYNhlShEmdqZVTGlOv50B5csTXsx/ywipI37rYgzQ3D1Ipk h73rNnSYh5xKzh48maP4MjiSkRvk/WqS4rvQBf9Sg/BjJk3V1RXM9fu6K0+YwZf38g3e mM5g== 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: ALoCoQkAGfM/RBNB2An4BWC/dmPK/rFmGZN4hJDw5dW3lK17SJuiVnqjE+rxm4beNmFIl62K7qxy 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-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 15:24:00 -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