From nobody Sun Apr 7 01:51:32 2024 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 4VBwF15Vl2z5Frf8 for ; Sun, 7 Apr 2024 01:51:33 +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 4VBwF14PPzz45tr for ; Sun, 7 Apr 2024 01:51:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1712454693; a=rsa-sha256; cv=none; b=eqETMlZcS1SGQDm/dOdjmmF/1my9AI6/Bdv/GQHCkAq55Zl7n0ZwUqpvYuvGyB4+1SO5CF zXyVgQSq5kpr1scNmTuvjMSIj2XmMwFmlwephDRX8k+csVCJWVFZG1BRTESyrguyZiqtnW JrcMePCagqI4rTduzccNC/E/yUEw4zZCFNvQmjZ2jcjq7GvTR74h11wyG3Rr08wp0ZstkG dOiZEnR/YIARbLVvbfNIYg6YQRkolDNwJELJKMAyxBs9YC4eS5Ld+yPDybGJddi6ES2HPK OC4IFPwiX+X28t3MIZvMLFDRhjaq7vuqGhejvhMY4SdQ2/2T9prsrDOvwFIjYw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1712454693; 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=+NrE8SeDgmkouuhZXlMUjpbCwAUI9ffz1IWFNtYW93g=; b=wYTugJJZtKHV8idXMM2xTHQFvPH6eaSMQW5oDZHKxMQkXdsFSPkOMUeLdmYBQlBTl4qBIB Rv493IAgSwKQ0bZu6QPH1LkuRZyC875BCoga5RaWfC2Zi2OVmHJ2Nyz3lIXc3h9qi90g57 6+FAj6AMoI4Cktqv09MBTYInqFYDPxAePyWXkZcQspPodhOz+2aou2Memwal3y+7mPqisj TFMTY+Wvq0wcMFAdPbdlxjDdAGQZ9dq/UAtf8A3CKGzyDKShqSXLSU/dlwCyDTPHp3oTmr w1r571dY0m8YD9o+0mQsibJC4wvHbulLoeZA+p5IcA+vdgx7ulSmBPSM4j9H/g== 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 4VBwF140q5z17Bg for ; Sun, 7 Apr 2024 01:51:33 +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 4371pXWL002389 for ; Sun, 7 Apr 2024 01:51:33 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4371pXYT002344 for bugs@FreeBSD.org; Sun, 7 Apr 2024 01:51:33 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 277886] ZFS boot loader gives up too easily on unsupported zpool flags Date: Sun, 07 Apr 2024 01:51:32 +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: 15.0-CURRENT X-Bugzilla-Keywords: loader X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: junchoon@dec.sakura.ne.jp X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277886 --- Comment #3 from Tomoaki AOKI --- (In reply to Xin LI from comment #2) > I think the ask is simply make check_feature() and check_mos_features() > (/stand/libsa/zfs/zfsimpl.c) to always return 0 instead of EIO even if > the feature is not supported, so probably the boot code would emit a lot = of > errors, but eventually somehow able to read in the kernel (which is suppo= sed > to have the support, as the upgrade happened when the kernel is running). Basically disagree, but agreed if only allowing "unsupported, enabled but n= ot active" features. At worst, broken (actually is in checksum mismatch and/or un-decompressed) kernel and modules are loaded, passed control and causing undefined behavio= ur, which can be fatal. > There may be some useful scenarios, for example, if a boot code that can't > support zstd compression is used, and boot file system never had zstd > compression, then the boot code should, in theory, be able to have suffic= ient > ability to boot from the pool. IIUC, it would be able to check whether the feature is active or not. Just to be enabled is not an actual problem, but once the feature is actual= ly used, the state becomes forcibly active (usually on first write access after enabled). If the code sizes of legacy zfsboot and gptzfsboot allows, it could be possible. Not sure how much space are left and how much codes are needed to implement. Maybe imp@ would be the best person to make decision here. > Personally I don't really like this idea, though, because it is not guara= nteed > to work and may expose bugs of the read-only code (because we now broke > the calling contract). It would be much better to prevent the upgrade fr= om > happening on the boot pool, and only allow it when boot environment is up= dated, > instead. Agreed. > If I was tasked to implement something for this, I'd probably do it by ex= tending > zpool utility to ask an OS dependent binary about "Is feature X supported= by > the current boot environment" for each read-only incompatible features, > if the pool have 'bootfs' set, and refuse to upgrade (unless -f is specif= ied) > these boot pools if any feature is not supported. Looks reasonable to me. But what's needed to be checked is NOT only the boot environment, but also the boot codes themselves, too. (As boot codes in freebsd-boot partition and/or ESP are not parts of ZFS BE= s.) Still remaining problem is that there could be any 3rd party boot loaders supporting boot FreeBSD from ZFS. > A naive implementation of the checker can be done by doing something like: > 1. Gather a list of all partitions that is "freebsd-boot" type or "efi" t= ype > (this is actually not right; the EFI partition should be mounted and the = actual > EFI/BOOT/BOOT${ARCH}.EFI should be checked instead), and append /boot/loa= der /boot/loader should be /boot/zfsloader, unless they are already the things = with different names for compatibility. Anyway, /boot/zfsloader should be prefer= red whenever it exists. Without it, upgrading from (could be non-supported) old versions which both were actually different, checking for /boot/loader clearly causes false-negative. > 2. Check if the feature string is present in the listed files, and return= false > if any of them do not have the string. Maybe the easiest (but far from perfect) way would be to implement codes fo= r it in zpool as FreeBSD-specific. Implementing for all supported OS'es by OpenZ= FS would be much harder and would be harder to be accepted by upstream. Checks for freebsd-boot pattition should be simply searching the whole partition. Possibly, gpart would be required to zero'ing whole partition before writing boot code to it, not to be confused by remnants of old contents. For ESP, yes, it should be mounted to check. And at least, the presense and contents of EFI/freebsd/loader.efi EFI/freebsd/boot1.efi (at least if EFI/freebsd/loader.efi does not exist) EFI/boot/boot${ARCH}.efi (including the check whether it's FreeBSD's one = or not) should be checked. To be paranoid, possibly, EFI/freebsd/BOOT${ARCH}.efi, t= oo? Oops...too many things to consider. And still, maybe I'm overlooking someth= ing fatal. But it's clearly worth considering to avoid unbootable OS'es. --=20 You are receiving this mail because: You are the assignee for the bug.=