Project Mu – A modular UEFI environment for building modern devices • Hacker News Board

Re: Project Mu – A modular UEFI environment for building modern devices

#21

Post by pgeorgi » Wed, Aug 14, 2019, 10:21 PM UTC

monocasa wrote: post #20

pgeorgi wrote: post #18

Earlier quoted context omitted.

Except for the parts in SMM (often considered "ring -2", below virtualization) that are installed by UEFI to implement stuff like Authenticated Variables (the thing that makes UEFI Secure Boot work and requires a rather complete crypto library for it). See https://firmware.intel.com/sites/default/files/resources/A_T...

That's not really UEFI though per se. Having an oracle in SMM is one option, but sticking them in the Management Engine/PSP or an expanded TPM are other options. And SMM is way older that UEFI. We'll almost certainly still have SMM after UEFI is gone.

> That's not really UEFI though per se. Having an oracle in SMM is one option, but sticking them in the Management Engine/PSP or an expanded TPM are other options.

It's UEFI code that's linked into a separate module. But it's the same code architecture (and largely the same code), just running in a different CPU mode.

> And SMM is way older that UEFI. We'll almost certainly still have SMM after UEFI is gone.

There are experiments at hardware vendors to get rid of SMM. While that will take approximately as long as the age-old attempts to retire legacy PC components (such as the RTC), it's not universally loved by vendors anymore.

Re: Project Mu – A modular UEFI environment for building modern devices

#22

Post by monocasa » Wed, Aug 14, 2019, 10:39 PM UTC

pgeorgi wrote: post #21

monocasa wrote: post #20

Earlier quoted context omitted.

That's not really UEFI though per se. Having an oracle in SMM is one option, but sticking them in the Management Engine/PSP or an expanded TPM are other options. And SMM is way older that UEFI. We'll almost certainly still have SMM after UEFI is gone.

> That's not really UEFI though per se. Having an oracle in SMM is one option, but sticking them in the Management Engine/PSP or an expanded TPM are other options. It's UEFI code that's linked into a separate module. But it's the same code architecture (and largely the same code), just running in a different CPU mode. > And SMM is way older that UEFI. We'll almost certainly still have SMM after UEFI is gone. There ar…

I mean, the management engine these days is the same code architecture, also loaded by UEFI. Is it the same thing?

And yeah I'm sure places like Google that control the whole stack have the ability and will to get rid of SMM for their own systems but that doesn't make sense for the vast majority of systems, particularly from white box vendors. As an example, new archs like AArch64 and RISC-V have equivalents in EL3/PSCI and Monitor Mode (mandated in all chips) respectively. The concept of a piece of code shipped by your board vendor running under the OS and hypervisor for system management tasks is just too useful of a concept.

Re: Project Mu – A modular UEFI environment for building modern devices

#23

Post by pgeorgi » Wed, Aug 14, 2019, 11:19 PM UTC

monocasa wrote: post #22

pgeorgi wrote: post #21

Earlier quoted context omitted.

> That's not really UEFI though per se. Having an oracle in SMM is one option, but sticking them in the Management Engine/PSP or an expanded TPM are other options. It's UEFI code that's linked into a separate module. But it's the same code architecture (and largely the same code), just running in a different CPU mode. > And SMM is way older that UEFI. We'll almost certainly still have SMM after UEFI is gone. There ar…

I mean, the management engine these days is the same code architecture, also loaded by UEFI. Is it the same thing? And yeah I'm sure places like Google that control the whole stack have the ability and will to get rid of SMM for their own systems but that doesn't make sense for the vast majority of systems, particularly from white box vendors. As an example, new archs like AArch64 and RISC-V have equivalents in EL3/P…

The Management Engine is very a different beast, if only because its code runs long before the main x86 CPU is even started (and UEFI can run). It also seems to run Minix these days (and before they moved the ME to the tiny Quark-style x86 core, some RTOS on an ARC core).

Unlike the ME firmware, SMM code is usually built with, shipped with and loaded by the x86 firmware.

Re: Project Mu – A modular UEFI environment for building modern devices

#24

Post by checktheorder » Thu, Aug 15, 2019, 12:31 AM UTC

pgeorgi wrote: post #12

snek wrote: post #11

Earlier quoted context omitted.

I'm looking forward to the "UEFI: The Good Parts" O'Reilly book.

s,book,leaflet,

"Do you have anything light?" https://www.youtube.com/watch?v=cxqjsyfbcd4

Re: Project Mu – A modular UEFI environment for building modern devices

#25

Post by non-entity » Thu, Aug 15, 2019, 12:55 AM UTC

pgeorgi wrote: post #23

monocasa wrote: post #22

Earlier quoted context omitted.

I mean, the management engine these days is the same code architecture, also loaded by UEFI. Is it the same thing? And yeah I'm sure places like Google that control the whole stack have the ability and will to get rid of SMM for their own systems but that doesn't make sense for the vast majority of systems, particularly from white box vendors. As an example, new archs like AArch64 and RISC-V have equivalents in EL3/P…

The Management Engine is very a different beast, if only because its code runs long before the main x86 CPU is even started (and UEFI can run). It also seems to run Minix these days (and before they moved the ME to the tiny Quark-style x86 core, some RTOS on an ARC core). Unlike the ME firmware, SMM code is usually built with, shipped with and loaded by the x86 firmware.

Pardon the interruption, but I know what all these term are (UEFI, ME, SMM) on a very cursory level, but this thread is sparking g my curiosity. Do you know of any good books / websites / etc. That docs good job of explaining how all these pieces work together in modern processors and firmware?

Re: Project Mu – A modular UEFI environment for building modern devices

#26

Post by userbinator » Thu, Aug 15, 2019, 1:42 AM UTC

bjt2n3904 wrote: post #10

If I were to build a "modern device", UEFI would be the last thing I'd want to put on it. I don't want to worry about exploits below ring 0 with a proprietary mess of binary blobs that lock me out of my own hardware.

Actually, "modern device" seems to mean "locked-down anti-user anti-backwards-compatibility walled garden" more than anything else, so I'd say the term is quite accurate. ;-)

Re: Project Mu – A modular UEFI environment for building modern devices

#27

Post by userbinator » Thu, Aug 15, 2019, 1:58 AM UTC

checktheorder wrote: post #9

pgeorgi wrote: post #5

Project Mu is mostly about getting the messy parts of the UEFI ecosystem sorted out: Instead of hoping that IBVs ("Independent BIOS Vendors") clean up their act (because, to be frank, they don't), they get ready-to-use components that Microsoft is using itself on the Surface products and provide a certain baseline standard (security, UX, ...). The difficult part about firmware in general (hardware initialization) is…

>the messy parts of the UEFI ecosystem The jokes practically write themselves.

Indeed. BIOS isn't perfect but it's small and simple and provides enough to boot an OS, whereas UEFI looks more like an attempt to create another OS to run before the main one. It's a great example of design-by-committee and second-system-syndrome.

Linus' rants on this topic are always worth a read: https://yarchive.net/comp/linux/efi.html

Re: Project Mu – A modular UEFI environment for building modern devices

#28

Post by xvilka » Thu, Aug 15, 2019, 3:13 AM UTC

It doesn't address the problem of binary blobs of platform initialization, the most important part of booting anyway. UEFI is just a glue, modern 64bit DOS, so can be dropped completely. Improving coreboot would have been a saner approach.

Re: Project Mu – A modular UEFI environment for building modern devices

#29

Post by bpye » Thu, Aug 15, 2019, 4:01 AM UTC

pgeorgi wrote: post #5

Project Mu is mostly about getting the messy parts of the UEFI ecosystem sorted out: Instead of hoping that IBVs ("Independent BIOS Vendors") clean up their act (because, to be frank, they don't), they get ready-to-use components that Microsoft is using itself on the Surface products and provide a certain baseline standard (security, UX, ...). The difficult part about firmware in general (hardware initialization) is…

Would be interesting to see Mu+Tianocore running on Coreboot, if it hasn't already been done.

Re: Project Mu – A modular UEFI environment for building modern devices

#30

Post by bpye » Thu, Aug 15, 2019, 4:02 AM UTC

pgeorgi wrote: post #21

monocasa wrote: post #20

Earlier quoted context omitted.

That's not really UEFI though per se. Having an oracle in SMM is one option, but sticking them in the Management Engine/PSP or an expanded TPM are other options. And SMM is way older that UEFI. We'll almost certainly still have SMM after UEFI is gone.

> That's not really UEFI though per se. Having an oracle in SMM is one option, but sticking them in the Management Engine/PSP or an expanded TPM are other options. It's UEFI code that's linked into a separate module. But it's the same code architecture (and largely the same code), just running in a different CPU mode. > And SMM is way older that UEFI. We'll almost certainly still have SMM after UEFI is gone. There ar…

Perhaps I'm missing something but isn't the RTC still used for time keeping when the computer is powered off? Legacy? Perhaps - but I don't know that there is a 1:1 replacement on PCs?