Bug 264090 - gpart bootcode safety checks
Summary: gpart bootcode safety checks
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: Unspecified
Hardware: amd64 Any
: --- Affects Some People
Assignee: Warner Losh
URL:
Keywords: needs-patch, needs-qa
Depends on:
Blocks:
 
Reported: 2022-05-19 23:44 UTC by Piotr Florczyk
Modified: 2023-09-11 09:39 UTC (History)
9 users (show)

See Also:
koobs: maintainer-feedback? (mav)
koobs: mfc-stable13?
koobs: mfc-stable12?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Florczyk 2022-05-19 23:44:34 UTC
gpart bootcode should at least check partition code before writing anything to disk and abort operation if it's not freebsd-boot.
  
This is unfortunately based on true story... I had to upgrade couple of servers which belong to our client. Those servers were installed using dual partition scheme which puts freebsd-boot as a second partition after efi.

gpart bootcode -p /boot/gptzfsboot -b /boot/pmbr -i1 da0 happily wiped efi partition (which on FreeBSD < 13.0 is not mounted) making servers unbootable. I don't have access to console, so admin on another side has to deal with effects of my muscle memory/incompetence. Considering that zpool upgrade, all blog/forum posts (related to bootcode) mention '-i1' overwriting wrong partition by accident is more than possible.

This issue (to some extent) might be related to bug #211503
Comment 1 Warner Losh freebsd_committer freebsd_triage 2022-05-20 02:13:39 UTC
why are you updating the boot code, used only on a BIOS/CMS system, on a UEFI system?

There's no doubt that some sanity checks could/should be added, but perhaps they are different than or in addition to the ones suggestion...
Comment 2 Warner Losh freebsd_committer freebsd_triage 2022-05-20 02:14:14 UTC
This isn't a fs@ issue.
Comment 3 Kurt Jaeger freebsd_committer freebsd_triage 2022-05-20 03:54:17 UTC
(In reply to Warner Losh from comment #1)
THere are cases where a disk moves from one hardware to another and
the other might boot from BIOS ?
Comment 4 Piotr Florczyk 2022-05-20 09:54:58 UTC
(In reply to Warner Losh from comment #1)
I know I don't have to but as I already mentioned... If you boot in UEFI installer always defaults to BIOS+UEFI scheme and places freebsd-boot as second partition. This changes holy index of that partition from 1 to 2.
I operate more than 100 of FreeBSD servers and this is first time I did a typo. One could say that this is combination of:
- defaults in the installer (partition order, I understand why it defaults to BIOS+UEFI)
- bad luck (efi partition not mounted on older installs)
- human error
but the point is it could be prevented if gpart did some checks.

If I understand correctly gpart bootcode overwrites first sector with code which seeks for partition type freebsd-boot. I see no reason in allowing writing boot code in other partition types.

I already had my lesson. This will prevent others from losing data. Currently only mounted partitions are protected.

Case mentioned by Kurt is also valid.
Comment 5 Xin LI freebsd_committer freebsd_triage 2022-05-30 01:56:58 UTC
I have been bite by a similar issue today.  Basically gpart bootcode happily wrote loader.efi (a PE binary) to the EFI partition as instructed.  PEBKAC, I know, but we could do better by performing some basic checks like the image written to EFI partion should be a FAT image, the freebsd-boot image should be greater than certain size and do not contain PE header or a FAT image, etc.