The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
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)

  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).