Re: [PLUG] Linux Install & school

(Apologies for top-posting; on mobile)

I 100% agree with Rich Mingin below, this sounds entirely like a UEFI ordering thing. Especially since your Ubuntu installer booted.

Was the UEFI menu *always* locked? Or did it lock "on its own" at a certain point? If the latter, did you disable SecureBoot? I've personally never seen Windows' bcfg lock on an EFI order/entry change, but I *have* seen it lock if the SecureBoot state changes OR if the volume is mounted from an external OS (like, say, a particularly nosy distro installer...).

(bcfg is kind of like Windows' version of GRUB.)

So one can lock the UEFI menu, but unless they're using a VERY advanced UEFI system (they aren't if it's commodity school hardware) that allows locking them... UEFI vars can be changed within a booted OS. Which is neat! (Or a nightmare if you're SecOps. For those wondering, the protection against this is removing/disabling any external booting - USB, CD/DVD, network, etc. - in UEFI, locking the UEFI menu, and only explicitly allowing keys that sign disk-installed kernels with SecureBoot. Remove the Microsoft general key, if trusted, AFTER e.g. Windows is installed so the key shim can't be used for e.g. linux OSes.)

Typically a new OS will "jump in line" to the first bootorder entry when it is installed.

Anyways, I just wanted to mention that you MAY need to use `efibootmgr -v` where Mingin below uses `efibootmgr`. Some versions default to a more terse output that only display the boot option's *name*, not the full boot path etc.

You also, depending on efibootmgr version, may not be able to use the `-a` flag. If not, use the `-o` option and provide an explicit boot order (comma-separated, no spaces) of the hex boot IDs. e.g.

efibootmgr -o DEAD,0001,BEEF

(I recommend just copying the BootOrder line's value from `efibootmgr`/`efibootmgr -v` output and swapping the order around. Some boards also allow duplicate entries in the order, some don't.)

You can also set a temporary "next boot" option, which sets the preferred/chosen boot entry only for the next reboot (`efibootmgr -b <BOOT ID> -n`, from memory).

Some excellent further reading for a rainy day:

https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface

https://wiki.archlinux.org/title/GRUB#UEFI_systems

https://wiki.archlinux.org/title/EFI_system_partition

(the disk-backed boot entries you see in efibootmgr are on ESPs)

https://wiki.archlinux.org/title/EFISTUB

(EFI lets you boot a kernel directly; you technically don't even need GRUB. I still recommend it though.)

On Tue, Jan 9, 2024, 23:44 Rich Mingin (PLUG) via plug <plug@lists.phillylinux.org> wrote:

Boot your Linux install (beginning of all great recovery sagas, IMHO)

Run a terminal of your choice.

Execute “efibootmgr”

Get this:

[forge@yorktown Downloads]$ efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0005,0006,0007,0008
Boot0000* rEFInd Boot Manager PciRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/NVMe(0x1,00-1B-44-8B-4B-34-B0-90)/HD(1,GPT,755a8321-8992-4df2-8095-3241db1d3f94,0x800,0x3ff800)/File(\EFI\refind\refind_x64.efi)0000
Boot0001* Windows Boot Manager HD(1,GPT,aabe95ad-0f09-47c9-b191-31adf188f8e7,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000033000100000010000000040000007fff0400
Boot0005* rEFInd Boot Manager PciRoot(0x0)/Pci(0x2,0x1)/Pci(0x0,0x0)/Pci(0x8,0x0)/Pci(0x0,0x0)/Pci(0x8,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-1B-44-8B-4B-34-0D-9D)/HD(1,GPT,2bbdbd0a-247e-4512-9852-59052683d750,0x800,0x3ff800)/File(\EFI\refind\refind_x64.efi)0000
Boot0006* UEFI:CD/DVD Drive BBS(129,,0x0)
Boot0007* UEFI:Removable Device BBS(130,,0x0)
Boot0008* UEFI:Network Device BBS(131,,0x0)
[forge@yorktown Downloads]$

(I installed Windows for you! The sacrifice! I've formatted it now, so all good.)

We can see a couple of boot options. They're not all files! These are all the ways your PC has been taught to boot up. Generally adding a new one does *not* remove others, that's a very big no-no in EFI. Find the one that specifically calls out Windows, in my case it's 0001. It's not in the "BootOrder" because I wiped that drive a while back, but the entry persists, because it wasn't hurting anything. To move that entry to the top of the list, I'd run:

efobootmgr -b 0001 -a

To delete it, since I'm never booting that copy of Windows again (or any, with luck), I run:
efibootmgr -b 0001 -B
(I actually had to run this with sudo since it's talking to hardware, YMMV)

which then results in:

[forge@yorktown Downloads]$ efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0005,0006,0007,0008
Boot0000* rEFInd Boot Manager PciRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/NVMe(0x1,00-1B-44-8B-4B-34-B0-90)/HD(1,GPT,755a8321-8992-4df2-8095-3241db1d3f94,0x800,0x3ff800)/File(\EFI\refind\refind_x64.efi)0000
Boot0005* rEFInd Boot Manager PciRoot(0x0)/Pci(0x2,0x1)/Pci(0x0,0x0)/Pci(0x8,0x0)/Pci(0x0,0x0)/Pci(0x8,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-1B-44-8B-4B-34-0D-9D)/HD(1,GPT,2bbdbd0a-247e-4512-9852-59052683d750,0x800,0x3ff800)/File(\EFI\refind\refind_x64.efi)0000
Boot0006* UEFI:CD/DVD Drive BBS(129,,0x0)
Boot0007* UEFI:Removable Device BBS(130,,0x0)
Boot0008* UEFI:Network Device BBS(131,,0x0)
[forge@yorktown Downloads]$

Good luck, have fun, and avoid those school IT guys, they sound like No Fun People.

On Tue, Jan 9, 2024 at 15:37 Rich Freeman via plug <plug@lists.phillylinux.org> wrote:
On Tue, Jan 9, 2024 at 3:04 PM Aaron Mulder via plug
<plug@lists.phillylinux.org> wrote:
>
> (even if we selected Windows from the Grub menu, Windows wanted a BitLocker recovery key because it noticed the changes, and we don’t have that for the school machine).

Well, Windows didn't notice the change so much as the TPM did. Most
likely it is configured to do a measured boot, so when the firmware
booted grub it hashed the grub EFI program and loaded that into the
write-once-per-reset TPM memory before executing grub. Then when
Bitlocker went to retrieve the key for the hard drive encryption the
TPM noted that the boot history had changed and refused to provide the
key. The recovery key would provide an alternate means of access -
without one or the other there is no way to decrypt the hard drive.

> I think the problem there is that the Ubuntu install changed the UEFI setup to put Grub higher in boot priority than Windows. Though I’m not sure, I don’t think it removed or corrupted the Windows boot loader, I think it just set Grub to be a higher priority. We couldn’t set it back because the UEFI menu is password-protected. Why could the Ubuntu installer change the boot priority but we need a password to change it back?

I'm not super-familiar with the EFI APIs/etc, but those might not
require a password. That suggests that an appropriate tool could edit
your EFI settings. Note that they need to be completely restored so
that the device firmware runs the same EFI executable that it did
before Ubuntu was installed, and not some kind of shim-loader. I'm
not familiar enough with these tools but I have a general idea of how
TPMs work.

TPMs are basically designed to keep people from doing this sort of
thing - if anything tries to load itself before your OS (like a
virus/rootkit/etc) it won't yield any stored keys, which are typically
used for disk encryption. You can do the same sort of thing on Linux,
though I'm not sure if any distros actually support it (the kernel
does, and I believe grub does as well, so I think it would just
require configuration to make it work). This is a pretty typical
secure configuration on laptops - at least the ones that don't run
Linux other than ChromeOS.

--
Rich
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug

___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug