From nobody Mon Feb 28 14:59:34 2022 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BE46819E3764 for ; Mon, 28 Feb 2022 14:59:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K6k7B4KPmz4mF2 for ; Mon, 28 Feb 2022 14:59:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 719F41D61D for ; Mon, 28 Feb 2022 14:59:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 21SExY1Y037562 for ; Mon, 28 Feb 2022 14:59:34 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 21SExYiQ037561 for bugs@FreeBSD.org; Mon, 28 Feb 2022 14:59:34 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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() Date: Mon, 28 Feb 2022 14:59:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.0-STABLE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: olivier.freebsd@free.fr X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: mfc-stable13? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1646060374; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6E+Xo2xLk9xBHI/ZCMxAtf5dt7itECrN6iUFXq/Hz+I=; b=PClBld6/LVhj+pVB8sIE8x0DqgL+OXY5VzizdWhWXEn25s5dNGoE/2WEfrdq9Ss6u00sr+ hBI6hrK/nm8UJMWUwmNoT98VphFtfaTM9dABtUaB+7HS0KT6QCG3EOiQGh7WUxDd1BgDn/ CFK03MJ6wZfip3dyaQrpaqLV2x3vmgMhjZA1u5vTxggtGOTHWjtKmo26XYPBWRj60vGd23 DLyCfvxu35DfeTzUa0sg34HeblELzGNLL2po+Tf2D7gH4Mp7oB71E8pja81/P3HBO2PRtB d0erBdYoUX0Yrbca/ZxwwY5x8Yt67OzlyqbPspyQJoVTkdV5zGhHuUM5pAP3ww== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1646060374; a=rsa-sha256; cv=none; b=KCheyzfSRo8Ocsn/1yDFsCT3+YJb96EKULMdf/12qw+7hoXvqRaKx91WHVscBG4jfkZlPR Fe1Lwf5VKcK7w/zB1+1+d85ZcwXrX8YdOw2DGGqnca5Pfv6d7eTSEt2TgX2urCl1OfYivC hC3QAMwIqPJNWfqpWNOdQngFuRBP9Xx32chrxO3sqjqrFW0oYt7OSeFlIHPk32NKmEBlwW lyKkFHbVfVrZAE3zgb4Lnavm7AX6PCJ0X2v1qnYdrUbdKZIfgOsj4NujmR5X/zJwNkx+Ap c/4YiHirqdqNj1FWkcVnbnizU7z15WiG0f3EqN+vtU5cenyTys0484cgWSRzGA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262192 --- Comment #5 from Olivier Certner --- (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.=