Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Damn Vulnerable UEFI

github.com

Post reply on HN
Print view View original

41–45 of 45 posts

Re: Damn Vulnerable UEFI

#41

Post by RulerOf »

p_l wrote: post #33
hulitu wrote: post #29

Earlier quoted context omitted.

> Did I mention how much easier handling booting with UEFI is compared to unholy mess of most other systems? Yeah. Like linux entries getting ignored, no eay to debug what went wrong (if an EFI executable fails, you're on your own). A shell which is undocumented. With BIOS i didn't spent hours trying to boot a linux kernel.

Unless you encountered a BIOS that actually followed the spec instead of blindly loaded a sector and hoped for the best, and learnt that your typical linux install programs made malformed MBR that does not mark the drive as bootable so BIOS actually should skip it when booting. Or when grub suddenly stops working on a dual boot system, and after you fix it another part on the non linux system fails, and if you fix th…

> That you can, worst case, boot it (or any other tools) from simple fat32 formatted pendrive that can be created with a file manager instead of rawdogging the hard disk is just a bonus.

There was a wonderful, brief period of time where most systems were UEFI out of the box, and the largest file on a Windows ISO was under 4 GiB.

You could literally drag+drop the contents of the ISO to a FAT32 thumb drive and install Windows with it. You didn't have to erase it first. You didn't need a special app or the command line to pull it off. It just worked.

The WIM files are too big now. At least Rufus is a pretty good utility.

Re: Damn Vulnerable UEFI

#42

Post by p_l »

crabbone wrote: post #31
AnthonyMouse wrote: post #14

Earlier quoted context omitted.

> How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile? It doesn't need to do this at all. Just make the flash accessible to the OS and have the OS do it. Machines without an OS can be booted into a live image. Put a write-protect jumper…

Absolutely this. Not sure which article that complained about EFI mentioned that PNG parser was vulnerable... and... there's no reason for EFI to have a PNG parser really. It's a fancy stuff that could've been totally avoided. And yet, here we go...

And it is an optional thing you don't need to have or use, but some people like graphical logos or even animated logos so there you go...

Re: Damn Vulnerable UEFI

#43

Post by p_l »

blueflow wrote: post #34
kokada wrote: post #32

Earlier quoted context omitted.

This isn't related to UEFI itself though.

Not directly, but making bootable images is much easier if your firmware is stateless and does not require setup with efibootmgr.

That's what fallback bootloader path is for, though...

Re: Damn Vulnerable UEFI

#44

Post by yencabulator »

AnthonyMouse wrote: post #14
harshreality wrote: post #10

Earlier quoted context omitted.

How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile? How do you build a BIOS successor that's not complicated when it needs to allow an OS to alter boot settings for the next boot? Granted, most of what goes on in a BIOS is displaying an…

> How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile? It doesn't need to do this at all. Just make the flash accessible to the OS and have the OS do it. Machines without an OS can be booted into a live image. Put a write-protect jumper…

> It doesn't need to do this at all. Just make the flash accessible to the OS and have the OS do it.

I fear this would lead to vendors only implementing proprietary, Windows-only, firmware update software. UEFI-based updates and "UEFI capsules" are better than a Windows-only world, even if UEFI is not necessarily the best thing ever.

Post reply on HN