Hello!
Warner Losh wrote in
<CANCZdfoy0UJyFdvJ_fO4FDks_dfEOhsJo+7p2RORdk6gQWf7qg@mail.gmail.com>:
|On Tue, Sep 5, 2023 at 9:53 AM Steffen Nurpmeso <steffen@sdaoden.eu> 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.)
Yes, for MBR, things are necessarily more complicated because the ZFS
boot loader is too big. The first few sectors live in the 8k space that the
traditional boot loader lives, and the rest is DD'd to a special area of the ZFS
uberblock reserved for boot blocks. For gptboot vs gptzfsboot, they were
written to be either or and combining them presented challenges, not least was
the partition size that gptboot lives in was created for many releases too small
to hold gptzfsboot and making it tricky to upgrade...
|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 less
|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=geli&apropos=0&sektion=0&manpath=FreeBSD+13.2-RELEASE+and+Ports&arch=default&format=html
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?
Yea. I find it easier :). But there's some better automation available in
Linux for the 'complicated' situations. I was also trying to be generous
to Linux because I know the passion of its supporters in the face of
even mild criticism.
Warner