Announcement

Collapse
No announcement yet.

Mark Shuttleworth Calls For An End To ACPI

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

  • #31
    Originally posted by tuubi View Post
    UEFI is quite complex, that's a given, but amount of documentation is hardly the best measure for software complexity in the general case. Then again, without reading either spec, I wonder if Open Firmware wouldn't need to be just a bit more complex to cover the whole scope of UEFI. Not that all the functionality UEFI provides is necessary or even desirable from a user's standpoint.
    The preferable UX is configuring your hardware from your native desktop. Coreboot enables that - UEFI doesn't. I'm not even sure you need the ability to select the boot device in the firmware if OSes got the ability to pick the reboot target. If you can manage that, it means you don't need keyboard drivers, usb initialization, etc in the firmware. It also helps fix the problem that tablets have where you can't input much to these devices in their firmware because you can't use bluetooth attachments.

    Comment


    • #32
      Originally posted by tuubi View Post
      UEFI is quite complex, that's a given, but amount of documentation is hardly the best measure for software complexity in the general case. [...] Not that all the functionality UEFI provides is necessary or even desirable from a user's standpoint.
      The problem is that if you try to make a UEFI implementation that you want to sell, you want to tick as many checkboxes with potential buyers as possible. So you try to make your implementation as complete as you can. With your QA resources spread thinly over the resulting huge codebase, less used parts will see not as much testing. Then you end up with a UEFI implementation where many functions are called not very often or at all.

      That this is a security problem was demonstrated by the Linux kernel in the past, where obscure network protocols have given rise to vulnerabilities several times.
      Last edited by chithanh; 18 March 2014, 10:11 AM.

      Comment


      • #33
        Originally posted by chithanh View Post
        The problem is that if you try to make a UEFI implementation that you want to sell, you want to tick as many checkboxes with potential buyers as possible. So you try to make your implementation as complete as you can. With your QA resources spread thinly over the resulting huge codebase, less used parts will see not as much testing. Then you end up with a UEFI implementation where many functions are called not very often or at all.

        That this is a security problem was demonstrated by the Linux kernel in the past, where obscure network protocols have given rise to vulnerabilities several times.
        I agree with you. UEFI is too big and covers functionality that belongs elsewhere or shouldn't exist at all. I should have made that clearer. Much of the spec seems to be about taking control away from the OS and the user instead of creating a better, safer or faster boot experience.

        Even the term "security" has been hijacked to be all about securing the rights of the corporations against the pesky users installing all kinds of crazy stuff on their new Macs or Windows laptops. You know, weird and highly suspicious things like Linux or other such WMD. We obviously don't know what we're doing (or maybe we do but that doesn't make them any money) so they'd better make sure we can't even try.

        Comment


        • #34
          First, there is need for a bootcode that works with ascii/vt100 only over a serial line!
          Last edited by dibal; 18 March 2014, 05:08 PM.

          Comment


          • #35
            And if the bootcode checks signatures for the first boot stages, it must have the possibility to check against my own certificates and the possibility to disable all other certificates!

            Comment

            Working...
            X