From owner-svn-src-all@freebsd.org Tue Sep 3 14:07:48 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DE816DD21F; Tue, 3 Sep 2019 14:06:57 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46N80128vVz4Q52; Tue, 3 Sep 2019 14:06:57 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id F07431AE1D; Tue, 3 Sep 2019 14:06:22 +0000 (UTC) X-Original-To: yuripv@localmail.freebsd.org Delivered-To: yuripv@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 770851E5B4; Tue, 16 Apr 2019 15:48:32 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 336BD6B710; Tue, 16 Apr 2019 15:48:32 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 19AD51E5B3; Tue, 16 Apr 2019 15:48:32 +0000 (UTC) Delivered-To: src-committers@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 611981E5B1 for ; Tue, 16 Apr 2019 15:48:29 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it1-f182.google.com (mail-it1-f182.google.com [209.85.166.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E0F86B70D; Tue, 16 Apr 2019 15:48:29 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it1-f182.google.com with SMTP id y10so33295445itc.1; Tue, 16 Apr 2019 08:48:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=c8OSmZizMKSpedgdZ2MjjS1Ff40fGdSwA9DCUazOA34=; b=rbXK5RYvAU9hjOJ4qKEsqB9DYbMQCh3lCjPVSvSdNUKfUgHGk9cfhAzv4469pBY0/m uR970pPtt7/lrPcuNRtMin8yx3U59fJRdjEcKukEUeJWNDMpd9nmXerzp8F1PSHhKFPD B8eaTlWYJrz3HJ6+8tDgB2B0WxQy0fASjAfL0I9Vtq0FuYRoeqYrliEPGJkbyKcDb8/i pRx0pmTR2WOiCKV9TMuBL8yiRAx640RmUvoxyXsDY19AFxZPStdds8Ky1PKB6FRYRQGp CXTB1WK54l79GDZtSPKYUE5jumyH4+njzZgodQyDvJaoGmsfmURNGXuhM6Umsbx1ow8O cSqw== X-Gm-Message-State: APjAAAUkN37EIF5KARwgi7MZmEQClxoMAt722fRC+pDIjM1CVEDSSkeY /aA3EeHb0AYOVJhEBy5dhr4Ol6VS X-Google-Smtp-Source: APXvYqzqpB/jGbvcszFPvJGLtlF/6otgk5kUsD1CglBI9gfl2i7pFUvutu+lnln5i8Q1aKNn7iqW7g== X-Received: by 2002:a24:2e06:: with SMTP id i6mr29810586ita.18.1555429707864; Tue, 16 Apr 2019 08:48:27 -0700 (PDT) Received: from mail-it1-f169.google.com (mail-it1-f169.google.com. [209.85.166.169]) by smtp.gmail.com with ESMTPSA id 25sm18245657iog.83.2019.04.16.08.48.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Apr 2019 08:48:27 -0700 (PDT) Received: by mail-it1-f169.google.com with SMTP id 139so33276160ita.4; Tue, 16 Apr 2019 08:48:27 -0700 (PDT) X-Received: by 2002:a05:660c:111:: with SMTP id w17mr30475578itj.62.1555429707511; Tue, 16 Apr 2019 08:48:27 -0700 (PDT) MIME-Version: 1.0 References: <201904151840.x3FIeaEQ009242@repo.freebsd.org> <20190416153816.GA20965@bsdpad.com> In-Reply-To: <20190416153816.GA20965@bsdpad.com> Reply-To: cem@freebsd.org From: Conrad Meyer X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys To: Ruslan Bukin Cc: src-committers , svn-src-all , svn-src-head Content-Type: text/plain; charset="UTF-8" Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 336BD6B710 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Status: O X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 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: , Date: Tue, 03 Sep 2019 14:07:48 -0000 X-Original-Date: Tue, 16 Apr 2019 08:48:16 -0700 X-List-Received-Date: Tue, 03 Sep 2019 14:07:48 -0000 Hi Ruslan, On Tue, Apr 16, 2019 at 8:38 AM Ruslan Bukin wrote: > > Hi I just got this: > > ... > _sleep() at random_harvest_deregister_source+0x132 > random_harvest_deregister_source() at read_random+0xc4 > read_random() at vn_fsync_buf+0x594 > vn_fsync_buf() at arc4rand+0xd4 > arc4rand() at sched_tdname+0x4c > sched_tdname() at mi_startup+0x20c > mi_startup() at 0xffffffc0000001a6 > KDB: enter: panic The stack is clearly bogus or missing some frames; can you attach GDB on this system (or an emulator) and get a full stack? The step(s) I'm missing are mi_startup -> sched_tdname, and sched_tdname -> arc4rand(). What's consuming random during early boot on riscv? (The vn_fsync_buf frame is also confusing and probably incorrect? A real stack would be helpful.) Maybe it's just __stack_chk_init, given mi_startup, like the other reproductions. I will need to take a step back from email to address that.) > We don't have loader(8) support for RISC-V and we don't have any hardware with random number generators yet. Most of our fpga/hardware has no way to have rootfs at all (we use mdroot). Is it possible to inject entropy into the mdroot? If not, it seems like anything that consumes random during early boot on riscv must be disabled. > We use BBL bootloader to boot freebsd. BBL embeds freebsd kernel to the BBL binary on a compile time (similar way how we embed mdroot to kernel). Once BBL initialized itself it jumps to the pre-defined address of payload which is freebsd kernel. > > So I'm pondering what is our current option, i.e. how to feed entropy in this case ? Can a running system rebuild the mdroot or BBL? Or do they reside on RO flash of some kind? If so, it would be possible to rewrite the BBL or mdroot with entropy injected for the next boot, I think. Otherwise, the straightforward solution is to simply disable anything that attempts to consume random early in boot on such devices with no hardware entropy source and no early filesystem access. Anything that is tripping on this was silently feeding itself with predictable, non-random data prior to this change. Best, Conrad