From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: Warner Losh <imp@bsdimp.com>
Cc: tuhs@tuhs.org
Subject: [TUHS] Re: Unix install & "standalone" package
Date: Thu, 07 Sep 2023 02:11:57 +0200 [thread overview]
Message-ID: <20230907001157.Qld6B%steffen@sdaoden.eu> (raw)
In-Reply-To: <CANCZdfoy0UJyFdvJ_fO4FDks_dfEOhsJo+7p2RORdk6gQWf7qg@mail.gmail.com>
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.)
|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?
--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)
next prev parent reply other threads:[~2023-09-07 0:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-04 14:44 [TUHS] " Norman Wilson
2023-09-04 14:55 ` [TUHS] " Vincenzo Nicosia
2023-09-04 17:20 ` Warner Losh
2023-09-04 19:05 ` Clem Cole
2023-09-05 17:03 ` Paul Winalski
2023-09-05 18:02 ` Clem Cole
2023-09-04 19:59 ` Theodore Ts'o
2023-09-04 23:51 ` Warner Losh
2023-09-04 17:18 ` Warner Losh
2023-09-04 22:10 ` Steffen Nurpmeso
2023-09-05 15:53 ` Steffen Nurpmeso
2023-09-06 17:50 ` Warner Losh
2023-09-07 0:11 ` Steffen Nurpmeso [this message]
2023-09-07 16:05 ` Warner Losh
2023-09-08 14:58 ` Theodore Ts'o
2023-09-08 13:56 ` Michael Kjörling
2023-09-08 23:38 ` Steffen Nurpmeso
2023-09-09 22:43 ` Steffen Nurpmeso
2023-09-11 4:10 ` Theodore Ts'o
2023-09-11 22:05 ` Steffen Nurpmeso
2023-09-05 1:07 ` Jonathan Gray
-- strict thread matches above, loose matches on Subject: below --
2023-09-04 9:57 [TUHS] " Paul Ruizendaal via TUHS
2023-09-04 14:53 ` [TUHS] " emanuel stiebler
2023-09-04 17:07 ` Warner Losh
2023-09-04 18:21 ` Dan Cross
2023-09-05 11:15 ` Paul Ruizendaal via TUHS
2023-09-05 14:15 ` Clem Cole
2023-09-05 17:03 ` Warner Losh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230907001157.Qld6B%steffen@sdaoden.eu \
--to=steffen@sdaoden.eu \
--cc=imp@bsdimp.com \
--cc=tuhs@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).