From owner-svn-src-head@FreeBSD.ORG Thu Oct 11 15:40:59 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 4ADF77B for ; Thu, 11 Oct 2012 15:40:59 +0000 (UTC) (envelope-from ache@vniz.net) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5A5458FC1B for ; Thu, 11 Oct 2012 15:40:58 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so1705327lbd.13 for ; Thu, 11 Oct 2012 08:40:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:openpgp :content-type:content-transfer-encoding:x-gm-message-state; bh=tnLnh6RanL8ZxeLsyVgc9SDcpjVLwwTzLNlYeF+8Eio=; b=G0V05Xlm6nzp7+px4lg4Ren3HuMhJbveGYhWMcwa1E7oCA0yqyN/PM0KzVObF2LFhY 6SkAyunm2Q80ZvD3ofuk1y+YwXLYX+sR/hPvq3X+aoFskU1GSzfilWRILdH4iNs2N+T8 rvMBDeYYuZ+MnfULzhq+/S+WZCPrYr10jchw5CHRBskEplHI33h23cphuPKwBWR3ZlPO RE3ln2AiSlrvHxIPTLDhIdBqumzNJG4g5X8A8bIM0oqAyfEaZCwmW4hP/DVJf66RRH0a hhKMUo/M3WOk4PM2LU/ZGW2ciPLa1TCJITDd5CsT8gAlfh4Zgw9vdbC3YDaVDR5ExBF5 OZXg== Received: by 10.112.99.37 with SMTP id en5mr642211lbb.1.1349970057271; Thu, 11 Oct 2012 08:40:57 -0700 (PDT) Received: from [192.168.1.2] ([89.169.140.97]) by mx.google.com with ESMTPS id y10sm1529249lbg.4.2012.10.11.08.40.56 (version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 08:40:56 -0700 (PDT) Sender: "Chernov, Andrey" Message-ID: <5076E880.9010502@freebsd.org> Date: Thu, 11 Oct 2012 19:40:48 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Peter Wemm Subject: Re: svn commit: r241373 - head/lib/libc/stdlib 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> In-Reply-To: OpenPGP: id=964474DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmDSqyeoDmKSIV3n7SoOnN7Nm6l/hTDEMJDD12+8vpEocymhUIEB4dt/P+z05T3+kFwxPyI 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:40:59 -0000 On 11.10.2012 19:23, Peter Wemm wrote: > 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? See /sys/libkern/arc4random.c #define ARC4_RESEED_SECONDS 300 i.e. first 5 minutes at least it is very bad seeded and vulnerable. But we don't have guarantee to have enough entropy even after first 5 minutes, it very depends of entropy sources turned on the machine configuration at whole (diskless, etc). Moreover, arc4random(3) code have its own reseed happens after arc4_count = 1600000; (divided by 4) iterations which increases bad seeded bytes initially taken from kernel's arc4 until whole count will be exhausted which is _very_ long time (consider that typical application issue only several rare arc4random(3) calls and exits, left arc4_count not decreased globally at all). > 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. I pass this subj to the people who knows clang compiler better to say for sure is it right to generate LLVM intermediate call void @srand(i32 undef) or not. Xoring the stack (or register) there is not essential step.