Announcement

Collapse
No announcement yet.

UEFI Makes It Easy To Boot Rust Applications

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by grigi View Post
    So in short, UEFI is the new BIOS, and generally just a regular advancement/evolution.
    No, UEFI isn't an evolution of BIOS.
    It is rewritten, redesigned and re-architectured from scratch.

    BIOS was simple and only did basic hardware initialization and not much else.
    Then it was ugly patched with hacks to make workarounds for limitations.

    UEFI is much more complex and does much more than BIOS and is actually like an operating system.
    It have its own network stack and can run programs and run multiple background services simultaneously.

    BIOS just got the hardware running and passed control the OS.
    UEFI does not pass control to the OS, because it never relinquishes control over the system to the OS, it always stays under the OS and can do its own stuff and runs it own stuff.
    UEFI is kind of like an operating system and hypervisor.

    Comment


    • #12
      Originally posted by uid313 View Post
      BIOS just got the hardware running and passed control the OS.
      UEFI does not pass control to the OS, because it never relinquishes control over the system to the OS, it always stays under the OS and can do its own stuff and runs it own stuff.
      UEFI is kind of like an operating system and hypervisor.
      Do you have a link for that? AFAIK, SMM is not related to UEFI, if that's what you mean.

      Comment


      • #13
        Originally posted by Pseus View Post
        Do you have a link for that? AFAIK, SMM is not related to UEFI, if that's what you mean.
        I think SMM (System Management Mode) is part of x86 or some extension to BIOS.
        But UEFI doesn't need SMM because it can run services.

        Comment


        • #14
          Originally posted by uid313 View Post
          No, UEFI isn't an evolution of BIOS.
          It is rewritten, redesigned and re-architectured from scratch.
          In practice, it does the same thing as the BIOS, it brings up the system, then loads an OS from one of the available devices, and dies. That's why it can be seen as an evolution of the BIOS, even if it is something different.

          BIOS was simple and only did basic hardware initialization and not much else.
          Then it was ugly patched with hacks to make workarounds for limitations.
          That's not true. Booting was only the first of the BIOS' functions. After booting, the BIOS kept providing the OS with runtime services, such as teletype I/O, disk I/O, graphics, memory management. But they stopped evolving those services after the 286 era, because back then people began to think that the OS was a better place to implement those functions. Which holds true also today for UEFI.

          UEFI is much more complex and does much more than BIOS and is actually like an operating system. It have its own network stack and can run programs and run multiple background services simultaneously.
          Still, UEFI is single threaded and its runtime services are non-reentrant.

          BIOS just got the hardware running and passed control the OS.
          UEFI does not pass control to the OS, because it never relinquishes control over the system to the OS, it always stays under the OS and can do its own stuff and runs it own stuff.
          UEFI is kind of like an operating system and hypervisor.
          After the OS calls ExitBootServices, most of the UEFI firmware is pretty much finished, and it only provides limited, basic services such as setting the time or writing environment variables.

          Comment


          • #15
            Originally posted by peppepz View Post
            In practice, it does the same thing as the BIOS, it brings up the system, then loads an OS from one of the available devices, and dies. That's why it can be seen as an evolution of the BIOS, even if it is something different.
            I was under the impression that UEFI loads the OS but stays resident and does not die.
            Am I wrong about this?

            Originally posted by peppepz View Post
            Still, UEFI is single threaded and its runtime services are non-reentrant.
            Please clarify, what do you mean with "runtime services are non-reentrant"?

            Comment


            • #16
              EFI defines two types of services: boot services and runtime services. Boot services are only available while the firmware owns the platform (before the ExitBootServices call). Boot services include text and graphical consoles on various devices, and bus, block and file services. Runtime services are still accessible while the operating system is running; they include services such as date, time and NVRAM access. In addition, the Graphics Output Protocol (GOP) provides limited runtime services support. The operating system is permitted to directly write to the framebuffer provided by GOP during runtime mode. However, the ability to change video modes is lost after transitioning to runtime services mode until the OS graphics driver is loaded.
              This is pretty scary.

              So a rootkit/trojan could be ran as a runtime service?

              Comment


              • #17
                Originally posted by uid313 View Post
                This is pretty scary.

                So a rootkit/trojan could be ran as a runtime service?
                Well if your rootkit can flash the UEFI firmware, yes, but I'm not sure it's possible remotely.
                On the other hand, I am not sure that you are much safer from malware that could flash a BIOS.

                Comment


                • #18
                  Originally posted by uid313 View Post
                  I think SMM (System Management Mode) is part of x86 or some extension to BIOS.
                  But UEFI doesn't need SMM because it can run services.

                  https://en.wikipedia.org/wiki/UEFI#Services
                  I was under the impression that those services are like the old BIOS interrupt calls, in the sense that they can only take control from the system during an explicit call by the OS or when running in SMM.

                  Comment


                  • #19
                    Originally posted by uid313 View Post
                    Please clarify, what do you mean with "runtime services are non-reentrant"?
                    That if you call one function, you can't call others before that function has returned.

                    I was under the impression that UEFI loads the OS but stays resident and does not die.
                    Am I wrong about this?
                    It stays as long as the EFI application doesn't call ExitBootServices. I think that the rationale is that utilities and bootloaders won't call it, so that they can run other EFI applications after they finish, while OS kernels will call it, so they can take ownership of the machine. After you call ExitBootServices, you as an application can only use a limited set of functions (http://wiki.phoenix.com/wiki/index.p...NTIME_SERVICES) and only as long as you don't do things that would confuse the UEFI implementation such as switching the processor to 32-bit mode.

                    UEFI implementations can survive (and continue harassing Linux ) even after the OS is loaded and has called ExitBootServices by means of SMM, as the BIOS used to do. I think that it's not possible at all to escape the SMM after it has been set up, UEFI or not.

                    Comment


                    • #20
                      Originally posted by erendorn View Post
                      Well if your rootkit can flash the UEFI firmware, yes, but I'm not sure it's possible remotely.
                      On the other hand, I am not sure that you are much safer from malware that could flash a BIOS.
                      But UEFI allows a EFI System partition on the disk from where it can executable EFI executables. So you don't really need to flash anything, just write a file to the disk.

                      Comment

                      Working...
                      X