[Bug 264282] BIOS boot from GELI encrypted broken / 'currdev' set to wrong string

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 03 Jun 2022 11:55:14 UTC

--- Comment #2 from yamagi@yamagi.org ---
I had a deeper look. This is a long standing bug, it's been there since
forever. bc9154a208248 exposed it and broke the BIOS bootloader on UFS on GELI
encrypted devices. ZFS is not broken, because it uses another code path.

The bootloader tracks devices in `devsw` structs. These structs have a field
`dv_name`, storing the name of the device type. For everything which qualifies
as a harddisk the string is just "disk". The  BIOS loader (i386 loader in the
code) derives the actual devicename from `dv_name` and some unit number magic,
drive C: ends up as unit 0. That happens in `i386_fmtdev()`.

GELI employs a hack: GELI devices are treated like disks, the GELI
initialisation code hijacks the `devsw` struct of the given disk and overwrites
it with a specialized version. The hack is explained in
stand/libsa/geli/gelidev.c:46. All lines are against 14-CURRENT as of
1326017849ee. This specialized version sets `dv_name` to "gelidisk". That's
were the wrong string comes from.

Until bc9154a208248 the `currdev` variable got set before GELI was initalized.
`dv_name` was still set to "disk". But with bc9154a208248 `currdev` is set
after GELI was initialized and `dv_name` is already "gelidisk". The code
doesn't take that into account and we end up with a wrong string.

I don't know enough about the bootloader to decide what the best fix is. We
could add logic to handle "gelidisk", since GELI disks are just disks that
looks overly complicated and error prone. We can introduce a new device type
`DEVT_GELI` or something like that. That would require a lot of code handling
that type, most of it would be a copy of the generic disk code. The easiest way
is to change "gelidisk" to just "disk". That should be okay, because there's no
code which handles "gelidisk" and GELI disks are disks.

The attached patch does exactly that. A oneliner, tested on my VM. I'm also
attaching a prebuild loader with the patch applied. It can be used to recover
bricked system, just replace /boot/loader with it.

You are receiving this mail because:
You are the assignee for the bug.