<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 6, 2023 at 6:12 PM Steffen Nurpmeso <<a href="mailto:steffen@sdaoden.eu">steffen@sdaoden.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
Warner Losh wrote in<br>
<<a href="mailto:CANCZdfoy0UJyFdvJ_fO4FDks_dfEOhsJo%2B7p2RORdk6gQWf7qg@mail.gmail.com" target="_blank">CANCZdfoy0UJyFdvJ_fO4FDks_dfEOhsJo+7p2RORdk6gQWf7qg@mail.gmail.com</a>>:<br>
|On Tue, Sep 5, 2023 at 9:53 AM Steffen Nurpmeso <<a href="mailto:steffen@sdaoden.eu" target="_blank">steffen@sdaoden.eu</a>> wrote:<br>
|> Steffen Nurpmeso wrote in<br>
|> <<a href="mailto:20230904221059.sF2G0%25steffen@sdaoden.eu" target="_blank">20230904221059.sF2G0%steffen@sdaoden.eu</a>>:<br>
|>|Norman Wilson wrote in<br>
|>| <<a href="mailto:9A989054DE79CE5059CBA74797391E39.for-standards-violators@oclsc.org" target="_blank">9A989054DE79CE5059CBA74797391E39.for-standards-violators@oclsc.org</a>>:<br>
|> ...<br>
|>||Perhaps the question to ask is why such a magic program is<br>
|>||needed at all. Is it just because programs like the shell<br>
|>||have become so large and unwieldy that they won't fit in<br>
|>||a small environment suitable for loading into an initramfs?<br>
|> ...<br>
|>|For my laptop it allows me easy boot management.<br>
...<br>
|> Only to add that this is because of Linux and the way it is doing<br>
|> things. If i would use FreeBSD on bare metal, then i would have<br>
|> an EFI boot loader on EFI that knows (only) enough to ask for<br>
|> passphrase (correct me if i am wrong), and can then boot the<br>
|> kernel from FFS or ZFS. (You have to choose dedicated ZFS boot<br>
|> loader iirc, but despite that...)<br>
|<br>
|No, you don't have to choose the dedicated ZFS boot loader, at least not<br>
|anymore.<br>
<br>
Ah! It seems regarding FreeBSD i am stuck in BIOS world, then.<br>
(zfsboot and gptzfsboot.)<br></blockquote><div><br></div><div>Yes, for MBR, things are necessarily more complicated because the ZFS<br></div><div>boot loader is too big. The first few sectors live in the 8k space that the</div><div>traditional boot loader lives, and the rest is DD'd to a special area of the ZFS</div><div>uberblock reserved for boot blocks. For gptboot vs gptzfsboot, they were</div><div>written to be either or and combining them presented challenges, not least was</div><div>the partition size that gptboot lives in was created for many releases too small</div><div>to hold gptzfsboot and making it tricky to upgrade...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
|Also, you can use boot1.efi to load loader.efi from the root filesystem to<br>
<br>
The former deprecated i see.<br>
<br>
|load the kernel, or you could use loader.efi directly on the ESP to load<br>
|the kernel. boot1 barely knows anything (and has only one choice of<br>
|what to boot). loader.efi is the full deal, and can do rather a lot of<br>
|sophisticated things.<br>
<br>
Great.<br>
<br>
...<br>
|> But anyhow. With an EFI_STUB Linux kernel i can save me all that,<br>
|> with busybox i get a complete environment (i then even create an<br>
|> initrd in /boot/ on the fly so i do not have to type the password<br>
|> a second time, that can (optionally) be cached, and is, actually<br>
...<br>
|> Unfortunately cryptsetup is needed even though, i think, the<br>
|> kernel has anything needed; you just cannot access it. cryptsetup<br>
|> is only needed for "$cs open $PART_ROOT p_root --key-file -".<br>
|> Of course i am no real Linux expert but only a do-it-yourself guy.<br>
<br>
Well, and user space only, and never having read BIOS or UEFI<br>
standards / implementations.<br>
I have reread (almost) all of FreeBSDs documentation (loader, uefi<br>
etc) today, and it is always great to see such good documentation!<br>
Of course some things are beyond what a "normal" user would<br>
understand, but at least there is documentation available.<br>
That is really great.<br>
<br>
|> busybox allows me to manage this easily, to answer your question.<br>
|<br>
|You could do that on FreeBSD with a loader.efi that has a ram disk<br>
|built into it as well, including a 'beastie box' thing that's akin to<br>
|busybox.<br>
|It will boot in one step and no no further I/O to get a running system.<br>
|Others have used this for secure boot and to boot a small ram disk that's<br>
|later discarded as userland decides what root should be. But it's much less<br>
|automated than in Linux...<br>
<br>
Hm, but wait. Isn't it easier for FreeBSD? I must admit i never<br>
used FreeBSD/geli on bare metal, i started using fully encrypted<br>
hard disks in mid 2021, no sooner. So when i read [1] it seems<br>
FreeBSD's boot procedure is so nicely linked with geli that the<br>
boot loader asks itself for the password of the encrypted<br>
partition, simply by setting some variables in loader.conf?<br>
I mean, the /boot/ must be available?<br>
<br>
[1] <a href="https://man.freebsd.org/cgi/man.cgi?query=geli&apropos=0&sektion=0&manpath=FreeBSD+13.2-RELEASE+and+Ports&arch=default&format=html" rel="noreferrer" target="_blank">https://man.freebsd.org/cgi/man.cgi?query=geli&apropos=0&sektion=0&manpath=FreeBSD+13.2-RELEASE+and+Ports&arch=default&format=html</a><br>
<br>
These simple scripts i use for Linux also do not support true<br>
suspend, only suspend-to-ram. Ie, i have no idea how i could<br>
"suspend" the encrypted device and then "resume" it again;<br>
The "warm" security is only (initiated via ACPI event from root<br>
account) auto-unload of SSH and PGP keys etc, unload of encfs fuse<br>
volumes, and then slock of all X displays etc. Ie, all programs<br>
which run live on the encrypted volume. When the laptop wakes up,<br>
X is running etc.<br>
One would need the possibility to wake up to "a password prompt".<br>
Well, likely it would work to mount EFI vfat before the suspend,<br>
create a console and auto-switch to it, and then sit there, ready<br>
for reading in the password once the system resumes. That is to<br>
say: i always believed in FreeBSD this works just as easy as the<br>
boot procedure?<br></blockquote><div><br></div><div>Yea. I find it easier :). But there's some better automation available in</div><div>Linux for the 'complicated' situations. I was also trying to be generous</div><div>to Linux because I know the passion of its supporters in the face of</div><div>even mild criticism.</div><div><br></div><div>Warner</div></div></div>