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

61–70 of 108 posts

Re: Twitter Client for UEFI

#61

Post by lmz »

dijit wrote: post #53
blibble wrote: post #40

Earlier quoted context omitted.

> this is so disingenuous as to be offensive. > I'm not saying you're wrong, but the practical options for replacing a UEFI BIOS are vanishingly small. what? you can download a GUI editor, click remove on the modules you don't want and then save it https://www.trishtech.com/2017/12/uefitool-view-and-edit-uef... I've done it

Cool tool, didn’t know it existed but there are so many variations on UEFI bios’s that I can’t help but feel it will not universally work, and it depends a lot on things being compartmentalised. I also draw your attention to: > UEFITool is only meant for the advanced users who have all the knowledge needed to modify the UEFI BIOS files. Because of you make any mistake and flash the faulty file to your motherboard, it…

On my consumer grade motherboards netboot and the UEFI network stack is off by default. Network access code is still there though for purposes like online update (manually done).

Re: Twitter Client for UEFI

#62

Post by dataflow »

blibble wrote: post #40
dijit wrote: post #35

Earlier quoted context omitted.

> if you're so inclined: you can remove unneeded modules from your UEFI firmware this is so disingenuous as to be offensive. I'm not saying you're wrong, but the practical options for replacing a UEFI BIOS are vanishingly small. Also: booting over the network is a feature of a smaller ROM on a network card, that ROM usually had a much smaller surface area and had to be explicitly called as a boot option. Given the pe…

> this is so disingenuous as to be offensive. > I'm not saying you're wrong, but the practical options for replacing a UEFI BIOS are vanishingly small. what? you can download a GUI editor, click remove on the modules you don't want and then save it https://www.trishtech.com/2017/12/uefitool-view-and-edit-uef... I've done it

Does it not need a digital signature or something?

Re: Twitter Client for UEFI

#63

Post by p_l »

hackettma wrote: post #13

This sounds like a perfect command and control setup for malware.

It's not really a good option, however SMM mode could be (you'd need to figure how to do network calls, though). The only thing changed by UEFI in this case is unified interface to register SMM components (You can have UEFI system with no SMM).

Re: Twitter Client for UEFI

#64

Post by p_l »

mwcampbell wrote: post #21

Has anyone implemented audio output on a modern x64 machine under UEFI, e.g. using the typical Realtek on-board audio? If so, I'd like to get a GUI with a screen reader working under UEFI sometime, both for the challenge of getting into bare-metal programming, and because as far as I know, nobody has made a PC boot process and firmware setup UI (what we used to call BIOS setup) accessible to blind people.

It would be very interesting project, because UEFI also puts emphasis on unified UI stack - yes, you can do stupid bling setup interface still, but there's somewhat unified UI toolkit available + standardised ways to create configuration options for devices.

This way, a screenreader could hook into the UI toolkit and provide a good interface.

Re: Twitter Client for UEFI

#65

Post by p_l »

dmix wrote: post #36
khaledh wrote: post #18

Earlier quoted context omitted.

As demonstrated by MoonBounce: https://securelist.com/moonbounce-the-dark-side-of-uefi-firm...

> Due to its emplacement on SPI flash which is located on the motherboard instead of the hard disk, the implant is capable of persisting in the system across disk formatting or replacement Lovely, so you’d have to reflash the firmware to fix it.

Was already the issue with BIOSes, in an era with much less interest in firmware security.

Re: Twitter Client for UEFI

#66

Post by p_l »

perryizgr8 wrote: post #43
blibble wrote: post #27

Earlier quoted context omitted.

what's the difference between having the code running in ring0 in a ROM vs the code running in ring0 from UEFI?

There's a huge difference. The network card does not need unrestricted access to the entire system.

There's less unrestricted access with UEFI than with old-fashioned option rom, especially with how you can 1) prevent loading of an option rom by banning its signature 2) register override for the device.

Also, now there's much less code in option rom, leading to much more coherent system. Yes, it is easier to attack, but so is any system where you can expect a standard ABI&API vs. one where you need to randomly poke things.

Re: Twitter Client for UEFI

#67

Post by p_l »

bonzini wrote: post #39
blibble wrote: post #33

Earlier quoted context omitted.

> The UEFI is persistently running at the background, has communication pipes with the OS this isn't true, it ceases running once it transfers execution you're thinking of the SMM, which is something else entirely

SMM is also part of the firmware, it is set up by UEFI.

UEFI provides an interface to register code that runs in SMM, true.

SMM being a requirement is a side effect of x86 history and platform design, not UEFI (which doesn't actually require SMM).

Re: Twitter Client for UEFI

#68

Post by p_l »

bayindirh wrote: post #31
blibble wrote: post #27

Earlier quoted context omitted.

what's the difference between having the code running in ring0 in a ROM vs the code running in ring0 from UEFI?

When a boot ROM fires (it was via INT19 IIRC), the boot ROM runs, terminates and leaves the system. The size is smaller, it's not persistent, and it can't communicate with anything on the OS. When booted from the ROM, it just downloads pxelinux.0 binary in most cases, and transfers control to it, and just vanishes. The UEFI is persistently running at the background, has communication pipes with the OS (some of it is…

UEFI is not persistent by itself - anything that is persistent was also persistent on BIOS-based systems. The only remaining elements of UEFI that are accessible after ExitBootServices() call (done by OS during boot) is interface to edit NVRAM variables and a way to register so-called "capsules" (used, for example, for firmware updates.)

Re: Twitter Client for UEFI

#69

Post by p_l »

dijit wrote: post #35
blibble wrote: post #22

Earlier quoted context omitted.

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

> if you're so inclined: you can remove unneeded modules from your UEFI firmware this is so disingenuous as to be offensive. I'm not saying you're wrong, but the practical options for replacing a UEFI BIOS are vanishingly small. Also: booting over the network is a feature of a smaller ROM on a network card, that ROM usually had a much smaller surface area and had to be explicitly called as a boot option. Given the pe…

The ROMs on NICs had huge attack surfaces, as each rom had to implement enough network stack from scratch. Not to mention how buggy they were.

There's a very good reason why iPXE is so often used for chainloading and why it has support for directly replacing the option rom of the card.

Re: Twitter Client for UEFI

#70

Post by poisonborz »

mwcampbell wrote: post #21

Has anyone implemented audio output on a modern x64 machine under UEFI, e.g. using the typical Realtek on-board audio? If so, I'd like to get a GUI with a screen reader working under UEFI sometime, both for the challenge of getting into bare-metal programming, and because as far as I know, nobody has made a PC boot process and firmware setup UI (what we used to call BIOS setup) accessible to blind people.

See this project: https://github.com/Goldfish64/AudioPkg
Post reply on HN