Date: Fri, 03 Jun 2022 11:55:14 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 264282] BIOS boot from GELI encrypted broken / 'currdev' set to wrong string Message-ID: <bug-264282-227-xgAuNCH72S@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-264282-227@https.bugs.freebsd.org/bugzilla/> References: <bug-264282-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264282 --- 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 G= ELI 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 qualif= ies as a harddisk the string is just "disk". The BIOS loader (i386 loader in t= he code) derives the actual devicename from `dv_name` and some unit number mag= ic, 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 overwr= ites 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 initaliz= ed. `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 handli= ng 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 recov= er bricked system, just replace /boot/loader with it. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-264282-227-xgAuNCH72S>