Date: Mon, 28 Feb 2022 14:59:34 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 262192] Crashes at boot with kern.random.initial_seeding.bypass_before_seeding=0 in randomdev_wait_until_seeded() Message-ID: <bug-262192-227-Kq94VQjqxh@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-262192-227@https.bugs.freebsd.org/bugzilla/> References: <bug-262192-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262192 --- Comment #5 from Olivier Certner <olivier.freebsd@free.fr> --- (In reply to Conrad Meyer from comment #4) Hi Conrad, > First order fix is to figure out why you don't have /boot/entropy > (or whatever) and fix that. (Most VMs don't have this problem.) Thanks for pointing this out. The image is entirely custom and indeed I did= n't generate some entropy file for boot. I could create "/boot/entropy" to avoid the panic, but I fear that this "solution" could actually threaten security in the following use case: Havi= ng a read-only image (VM, CD-ROM or USB) that is always used to boot a machine. In this case, the same "/boot/entropy" will be used over and over, leading = to the same guard at each boot (similarly to the static guard used in the code before e199792d23341b0a; the only slight advantage is that the static guard would not be known in advance by simple source code inspection). Worse, it consumes only part of the entropy, so later subsystems using arc4rand() will also consume the same entropy boot after boot, until no more entropy is available and the generator has to be reseeded. If my reasoning is correct, this means that providing a constant "/boot/entropy" will effectively, for the first routines needing random numbers, bypass the security offered by "kern.random.initial_seeding.bypass_before_seeding set to 0". Don't know the practical extent of the problem (who does request random bytes at boot, and= for what), but this is a priori worrying. >Second order workaround is to revert e199792d23341b0a887bf54c262147b213edd= 556 > and set security.stack_protect.permit_nonrandom_cookies=3D1. > This is practically similar to not compiling in stackcookies at all. At least, this solution avoids these concerns, at the price of a static gua= rd. I agree that this means no stack cookies at all, but only in the perspectiv= e of a deliberate attack (the mechanism stays useful to uncover stack overflow b= ugs) and provided I don't change the hardcoded value myself (then the canary wou= ld still have to be discovered once, as if the same "/boot/loader.conf" is used over and over; this is weaker than the current vanilla randomization). > Third option is to set kern.random.initial_seeding.bypass_before_seeding= =3D1. Yes, but that's precisely what I've been trying to avoid from the start. I = want the random source to always be seeded; if it is not then the system has to = wait until there is enough entropy. > Could this be better? Sure. (snip) Interesting possibilities to look at. Thanks. I may look at that (not before several weeks, unfortunately) if Kyle doesn't in the meantime. Don't know the inner details of SSP, but is the same guard used for all processes/threads? I assume that __stack_chk_guard is salted with specific process/thread info, or some other random source. So it might possible to l= ive with a static guard initially (influencing only some kernel processes) and = then change it while entropy is available (for all later processes/threads). Do = you think it's a viable idea? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-262192-227-Kq94VQjqxh>