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

Twitter Client for UEFI

github.com

Post reply on HN
Print view View original

81–90 of 108 posts

Re: Twitter Client for UEFI

#81

Post by LASR »

jotm wrote: post #78
ctxc wrote: post #10

Didn't know what UEFI was, so here it is: " UEFI and BIOS are low-level software that starts when you boot your PC before booting your operating system, but UEFI is a more modern solution, supporting larger hard drives, faster boot times, more security features, and—conveniently—graphics and mouse cursors. The UEFI/BIOS loads when your computer starts up, and the BIOS is responsible for waking up your computer’s hard…

This should be common knowledge among everyone using a computer. It just makes sense to know how your device operates, and it's not hard to learn. Having been the go to guy for fixing anything remotely computer related, I got sick of it and I just wish everyone could fix their own stuff :D

You seem to have a frustration with people around you.

I don’t think the problem is with what people should know, but don’t.

Re: Twitter Client for UEFI

#82

Post by matth3 »

jotm wrote: post #78
ctxc wrote: post #10

Didn't know what UEFI was, so here it is: " UEFI and BIOS are low-level software that starts when you boot your PC before booting your operating system, but UEFI is a more modern solution, supporting larger hard drives, faster boot times, more security features, and—conveniently—graphics and mouse cursors. The UEFI/BIOS loads when your computer starts up, and the BIOS is responsible for waking up your computer’s hard…

This should be common knowledge among everyone using a computer. It just makes sense to know how your device operates, and it's not hard to learn. Having been the go to guy for fixing anything remotely computer related, I got sick of it and I just wish everyone could fix their own stuff :D

Why stop at using a computer, you could apply this sentiment to every item anyone may use.

We should all have a decent grasp of molecule rotation and the electric dipole moment before zapping that meal in the microwave!

Re: Twitter Client for UEFI

#83

Post by tomc1985 »

lizardactivist wrote: post #5

I get the feeling UEFI can never be entirely secure with the set of functionality it offers and thus huge surface it is exposing. Call me crazy, but security means doing only what is necessary and no more, in particular in this early part of starting up a computer system.

Yeah I really don't understand why this crap needs to be so capable.

You can already do all sorts of tricks with net booting, any HTTP stack needs can be deferred to run in the OS.

I worked extensively with UEFI in a past job and every implementation I could find had large bugs of some kind. It is fine at booting the system but managing it is a nightmare, and it seems like UEFI prompt is designed to be as obtuse as possible. And I didn't even know it could do HTTP calls!

Re: Twitter Client for UEFI

#84

Post by tomc1985 »

blibble wrote: post #22
profile53 wrote: post #14

Earlier quoted context omitted.

What’s scary about UEFI is that it has both direct hardware access and a massive attack surface: GUI, Ethernet stack, occasionally an 802.11 stack, etc.

customers want to be able to boot their machines off the network this would be difficult without a network stack if you're so inclined: you can remove unneeded modules from your UEFI firmware

You can boot to a stub OS on the system that can chainload whatever you want afterwards. This is how GRUB et al work.

Re: Twitter Client for UEFI

#85

Post by saghm »

profile53 wrote: post #14
______-_-______ wrote: post #11

Earlier quoted context omitted.

UEFI needs ~complete access to the machine so it can initialize hardware devices and pass control to the OS (which also has ~complete control of the hardware). How do you think sandboxing it would work, practically?

What’s scary about UEFI is that it has both direct hardware access and a massive attack surface: GUI, Ethernet stack, occasionally an 802.11 stack, etc.

Yeah, every time I have to update my bios over ethernet, I kind of just shudder internally. Downloading and flashing is a pain, but it still just feels wrong for some reason.

Re: Twitter Client for UEFI

#86

Post by diego_sandoval »

ctxc wrote: post #10

Didn't know what UEFI was, so here it is: " UEFI and BIOS are low-level software that starts when you boot your PC before booting your operating system, but UEFI is a more modern solution, supporting larger hard drives, faster boot times, more security features, and—conveniently—graphics and mouse cursors. The UEFI/BIOS loads when your computer starts up, and the BIOS is responsible for waking up your computer’s hard…

For anyone wanting to know how UEFI actually works, I always recommend this article: https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how...

Re: Twitter Client for UEFI

#87

Post by mjg59 »

WaitWaitWha wrote: post #80
Sophira wrote: post #60

Earlier quoted context omitted.

> and finally your very safe and secure OS running. That's the one running on the Intel Management Engine, right? Or at least Intel would like to believe that's the case. Jokes aside, I may be missing something. The BIOS came way before UEFI did. What am I missing here?

UEFI did not replace the BIOS. You must have an onboard storage (usually a EEPROM)that loads all the UEFI. To load the UEFI, it still needs to know about devices and such, so that onboard thing albeit we no longer allowed to call BIOS, is... the BIOS. It is the 0 stage loader, or pre-loader, or pre-UEFI boot loader; just do not call it BIOS because it hurt feelings. So what is being sold is: old way is BIOS --> MBR -…

> Something has to start reach and load the UEFI written on a 'boot media'

No. The UEFI stack lives entirely in flash, the same as BIOS did.

Re: Twitter Client for UEFI

#88

Post by m463 »

profile53 wrote: post #14
______-_-______ wrote: post #11

Earlier quoted context omitted.

UEFI needs ~complete access to the machine so it can initialize hardware devices and pass control to the OS (which also has ~complete control of the hardware). How do you think sandboxing it would work, practically?

What’s scary about UEFI is that it has both direct hardware access and a massive attack surface: GUI, Ethernet stack, occasionally an 802.11 stack, etc.

Many uefi systems do lots of "fun things" because they have network access.

Take a look at ASUS motherboards, which has Armory Crate in UEFI. It will download and install software in your windows install.

...automatic bloatware from the bios.

Re: Twitter Client for UEFI

#89

Post by erosenbe0 »

matth3 wrote: post #82
jotm wrote: post #78

Earlier quoted context omitted.

This should be common knowledge among everyone using a computer. It just makes sense to know how your device operates, and it's not hard to learn. Having been the go to guy for fixing anything remotely computer related, I got sick of it and I just wish everyone could fix their own stuff :D

Why stop at using a computer, you could apply this sentiment to every item anyone may use. We should all have a decent grasp of molecule rotation and the electric dipole moment before zapping that meal in the microwave!

I'd probably wreck meals less if I understood how microwaves act on foods with varying moisture and lipid proportions.

Re: Twitter Client for UEFI

#90

Post by mjg59 »

A few thoughts: yes, UEFI is a large attack surface. Secure Boot mitigates a lot of that - if it's turned on, the vast majority of UEFI functionality is only accessible to signed binaries. If you're running untrustworthy code in your boot environment then it's already in a position to just overwrite the firmware, there's no memory protection here. But UEFI doesn't entirely go away after the OS boots, there's some number of runtime services left that the OS depends on. http://blog.frizk.net/2017/01/attacking-uefi-and-linux.html is a demonstration that if you're able to modify those then you can compromise the OS. There's also, of course, all the code in SMM which can just do whatever and may have been audited but possibly hasn't been.

But honestly overall BIOS was a bigger concern than UEFI. It's easy to forget, but a lot of the BIOS hooks are still available at runtime - https://github.com/mqudsi/lrmi is an interface that lets you call them from Linux. It's reasonable to worry about the attack surface exposed by UEFI runtime services, but BIOS software interrupts are frankly even weirder. The reason we largely didn't worry about them is that you normally have to be root to call them, which is also the case for UEFI runtime services and most SMM interfaces. And SMM definitely predates UEFI, so getting away from UEFI complexity wouldn't save us there.

And there's been plenty of meaningful security work done in the UEFI space lately. There's support for proper IOMMU setup so that you can boot off Thunderbolt without any Thunderbolt device just being able to DMA all over your firmware. The NX bit is supported. There's support for stack canaries. There are best practices for SMM behaviour. https://uefi.org/sites/default/files/resources/UEFI%20Firmwa... covers a bunch of this.

If we were designing firmware for maximum security then I don't think anyone would argue we'd come up with UEFI. That doesn't mean that we should be nostalgic about BIOS, which was a smaller attack surface but provided no meaningful security.

Post reply on HN