From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8354 invoked from network); 7 Sep 2023 00:12:22 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 7 Sep 2023 00:12:22 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 84C01409B7; Thu, 7 Sep 2023 10:12:13 +1000 (AEST) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) by minnie.tuhs.org (Postfix) with ESMTPS id 0474240920 for ; Thu, 7 Sep 2023 10:12:02 +1000 (AEST) Date: Thu, 07 Sep 2023 02:11:57 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Warner Losh Message-ID: <20230907001157.Qld6B%steffen@sdaoden.eu> In-Reply-To: References: <9A989054DE79CE5059CBA74797391E39.for-standards-violators@oclsc.org> <20230904221059.sF2G0%steffen@sdaoden.eu> <20230905155301.mIziN%steffen@sdaoden.eu> Mail-Followup-To: Warner Losh , Norman Wilson , tuhs@tuhs.org User-Agent: s-nail v14.9.24-507-g0e7e3e8c46 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: WA4P2F4C5JHQ7WJE2YHYLPXITRTGYAGC X-Message-ID-Hash: WA4P2F4C5JHQ7WJE2YHYLPXITRTGYAGC X-MailFrom: steffen@sdaoden.eu X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Unix install & "standalone" package List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hello! Warner Losh wrote in : |On Tue, Sep 5, 2023 at 9:53=E2=80=AFAM Steffen Nurpmeso wrote: |> Steffen Nurpmeso wrote in |> <20230904221059.sF2G0%steffen@sdaoden.eu>: |>|Norman Wilson wrote in |>| <9A989054DE79CE5059CBA74797391E39.for-standards-violators@oclsc.org>: |> ... |>||Perhaps the question to ask is why such a magic program is |>||needed at all. Is it just because programs like the shell |>||have become so large and unwieldy that they won't fit in |>||a small environment suitable for loading into an initramfs? |> ... |>|For my laptop it allows me easy boot management. ... |> Only to add that this is because of Linux and the way it is doing |> things. If i would use FreeBSD on bare metal, then i would have |> an EFI boot loader on EFI that knows (only) enough to ask for |> passphrase (correct me if i am wrong), and can then boot the |> kernel from FFS or ZFS. (You have to choose dedicated ZFS boot |> loader iirc, but despite that...) | |No, you don't have to choose the dedicated ZFS boot loader, at least not |anymore. Ah! It seems regarding FreeBSD i am stuck in BIOS world, then. (zfsboot and gptzfsboot.) |Also, you can use boot1.efi to load loader.efi from the root filesystem to The former deprecated i see. |load the kernel, or you could use loader.efi directly on the ESP to load |the kernel. boot1 barely knows anything (and has only one choice of |what to boot). loader.efi is the full deal, and can do rather a lot of |sophisticated things. Great. ... |> But anyhow. With an EFI_STUB Linux kernel i can save me all that, |> with busybox i get a complete environment (i then even create an |> initrd in /boot/ on the fly so i do not have to type the password |> a second time, that can (optionally) be cached, and is, actually ... |> Unfortunately cryptsetup is needed even though, i think, the |> kernel has anything needed; you just cannot access it. cryptsetup |> is only needed for "$cs open $PART_ROOT p_root --key-file -". |> Of course i am no real Linux expert but only a do-it-yourself guy. Well, and user space only, and never having read BIOS or UEFI standards / implementations. I have reread (almost) all of FreeBSDs documentation (loader, uefi etc) today, and it is always great to see such good documentation! Of course some things are beyond what a "normal" user would understand, but at least there is documentation available. That is really great. |> busybox allows me to manage this easily, to answer your question. | |You could do that on FreeBSD with a loader.efi that has a ram disk |built into it as well, including a 'beastie box' thing that's akin to |busybox. |It will boot in one step and no no further I/O to get a running system. |Others have used this for secure boot and to boot a small ram disk that's |later discarded as userland decides what root should be. But it's much le= ss |automated than in Linux... Hm, but wait. Isn't it easier for FreeBSD? I must admit i never used FreeBSD/geli on bare metal, i started using fully encrypted hard disks in mid 2021, no sooner. So when i read [1] it seems FreeBSD's boot procedure is so nicely linked with geli that the boot loader asks itself for the password of the encrypted partition, simply by setting some variables in loader.conf? I mean, the /boot/ must be available? [1] https://man.freebsd.org/cgi/man.cgi?query=3Dgeli&apropos=3D0&sektion= =3D0&manpath=3DFreeBSD+13.2-RELEASE+and+Ports&arch=3Ddefault&format=3Dhtml These simple scripts i use for Linux also do not support true suspend, only suspend-to-ram. Ie, i have no idea how i could "suspend" the encrypted device and then "resume" it again; The "warm" security is only (initiated via ACPI event from root account) auto-unload of SSH and PGP keys etc, unload of encfs fuse volumes, and then slock of all X displays etc. Ie, all programs which run live on the encrypted volume. When the laptop wakes up, X is running etc. One would need the possibility to wake up to "a password prompt". Well, likely it would work to mount EFI vfat before the suspend, create a console and auto-switch to it, and then sit there, ready for reading in the password once the system resumes. That is to say: i always believed in FreeBSD this works just as easy as the boot procedure? --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)