Date: Tue, 16 Apr 2019 15:49:14 -0700 From: Conrad Meyer <cem@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys Message-ID: <CAG6CVpWu3eaCqe2cYS8FdAna30q58UT3KTiYHjxfv7Yo052dDg@mail.gmail.com> In-Reply-To: <457a2c63-f062-8fc6-15d4-6f5b93981930@FreeBSD.org> References: <201904151840.x3FIeaEQ009242@repo.freebsd.org> <457a2c63-f062-8fc6-15d4-6f5b93981930@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 16, 2019 at 2:32 PM John Baldwin <jhb@freebsd.org> wrote: > There are definitely places arc4random is used where sleeping is not allowed. Sure. > ipsec generating nonces for AES-CBC is one example I can think of off the > top of my head. IVs for AES-CBC are also a great example of a case we should be seeded for. > I think it might be useful to add an explicit WITNESS_WARN > in arc4random to catch these cases so they can be found and reasoned about. Well, we kind of want that, but we also want the warning to disappear if the consumer has correctly reasoned about it. E.g., if the thread has verified seeded status with is_random_seeded(), it is no longer possible for a arc4random consumption to block. Right? I think that may be difficult to integrate with the WITNESS_WARN, so even if all consumers are correctly implemented, we will not eliminate the witness warnings. Do you have any ideas? The only dumb proposal I have is burning a flag in td_flags for "this thread checked is_random_seeded(), and it returned true." > Note that I actually often run into unseeded systems when doing development > using qemu for non-x86 architectures. For example, when booting mips from > qemu, there is no loader, the kernel just starts, and since the endian is > opposite, I frequently regenerate the filesystem using makefs. Right. Perhaps we could incorporate boot/entropy generation into makefs? Or pass host entropy into some kernel accessible region (env var, whatever) via qemu? The latter is sort of a general problem for VMs. You want to be able to snapshot and clone a VM without producing reproducible RNG state, but Fortuna doesn't handle that explicitly (aside from future entropy differences and forward secrecy causing quick divergence). Best, Conrad
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpWu3eaCqe2cYS8FdAna30q58UT3KTiYHjxfv7Yo052dDg>