4 ms·

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

bayindirh 5y ago
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 visible via /sys/firmware/efi), and has much larger surface like direct access to disks and network stack via drivers (it can directly read your files and work on them via proper FS driver modules). There's also at least one open source sound driver too (https://github.com/Goldfish64/AudioPkg https://github.com/Goldfish64/AudioPkg), so it can listen to your environment if it wants, at least in theory.
- blibble 5y ago
  > 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
  - bonzini 5y ago
    SMM is also part of the firmware, it is set up by UEFI.
    - blibble 5y ago
      yes, the UEFI initialises the machine such that it is in a state that it can boot that's it's job it's not the fault of the UEFI as a standard or implementation that your processor manufacturer chose to require the SMM to have its firmware loaded to boot the UEFI also isn't suddenly persistent because there are other devices inside the machine that had firmware loaded into them (would you say the UEFI is persistent because it uploaded new third-party supplied microcode into the CPU?)
    - p_l 5y ago
      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).
      - hackmiester 5y ago
        I don't think SMM requires UEFI, either, actually... I believe there have been BIOSes that initialized SMM also.
        p_l 5y ago
        Indeed. SMM exists because it was unfeasible to require the OS to provide necessary power management features at a time when running DOS and unmodified Win2.x and Win3.x were crucial features. Thus 386SL was born, with SMM mode so that the firmware could hijack DOS without being stopped by accidental modification of interrupt table. A bunch of stuff was later loaded into SMM for various reasons, both more and less benign. Turion X2 CPUs used SMM resident handler to synchronise cpus when going into deeper sleep levels (iirc C3 required the SMM handler, C1 and C2 were doable without, but C1E required it as well)
        deleted 5y ago
        [deleted]
      - bonzini 5y ago
        UEFI Secure Boot requires SMM (because it secures access to the key vault). Non-x86 architectures use something else, for example they could use EL3 on ARM. Either way it's a "super-supervisor mode" of sorts.
        p_l 5y ago
        Well, it does not have to be SMM that does it - it's just that SMM is what we have already available so unless you have certain rare hw it's what vendors will use :(
- mwcampbell 5y ago
  > There's also at least one open source sound driver too Looking on the bright side, that means the firmware can potentially also talk to you if you can't see the screen.
- p_l 5y ago
  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.)
perryizgr8 5y ago
There's a huge difference. The network card does not need unrestricted access to the entire system.
- blibble 5y ago
  it has it because the code running from its ROM is running in ring0 exactly the same as the UEFI
- p_l 5y ago
  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.
- ikiris 5y ago
  You do know how DMA works right?

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 visible via /sys/firmware/efi), and has much larger surface like direct access to disks and network stack via drivers (it can directly read your files and work on them via proper FS driver modules). There's also at least one open source sound driver too (https://github.com/Goldfish64/AudioPkg https://github.com/Goldfish64/AudioPkg), so it can listen to your environment if it wants, at least in theory.

blibble 5y ago
> 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
- bonzini 5y ago
  SMM is also part of the firmware, it is set up by UEFI.
  - blibble 5y ago
    yes, the UEFI initialises the machine such that it is in a state that it can boot that's it's job it's not the fault of the UEFI as a standard or implementation that your processor manufacturer chose to require the SMM to have its firmware loaded to boot the UEFI also isn't suddenly persistent because there are other devices inside the machine that had firmware loaded into them (would you say the UEFI is persistent because it uploaded new third-party supplied microcode into the CPU?)
  - p_l 5y ago
    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).
    - hackmiester 5y ago
      I don't think SMM requires UEFI, either, actually... I believe there have been BIOSes that initialized SMM also.
      - p_l 5y ago
        Indeed. SMM exists because it was unfeasible to require the OS to provide necessary power management features at a time when running DOS and unmodified Win2.x and Win3.x were crucial features. Thus 386SL was born, with SMM mode so that the firmware could hijack DOS without being stopped by accidental modification of interrupt table. A bunch of stuff was later loaded into SMM for various reasons, both more and less benign. Turion X2 CPUs used SMM resident handler to synchronise cpus when going into deeper sleep levels (iirc C3 required the SMM handler, C1 and C2 were doable without, but C1E required it as well)
      - deleted 5y ago
        [deleted]
    - bonzini 5y ago
      UEFI Secure Boot requires SMM (because it secures access to the key vault). Non-x86 architectures use something else, for example they could use EL3 on ARM. Either way it's a "super-supervisor mode" of sorts.
      - p_l 5y ago
        Well, it does not have to be SMM that does it - it's just that SMM is what we have already available so unless you have certain rare hw it's what vendors will use :(
mwcampbell 5y ago
> There's also at least one open source sound driver too Looking on the bright side, that means the firmware can potentially also talk to you if you can't see the screen.
p_l 5y ago
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.)

perryizgr8 5y ago

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

blibble 5y ago
it has it because the code running from its ROM is running in ring0 exactly the same as the UEFI
p_l 5y ago
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.
ikiris 5y ago
You do know how DMA works right?