Announcement

Collapse
No announcement yet.

Intel Planning To End Legacy BIOS Support By 2020

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

  • #31
    Originally posted by Tomin View Post
    It used to be common to flash new BIOS versions with FreeDOS memory stick or CD. How much there is need for that with current UEFI boards? I know that usually you can flash it within UEFI menu and some boards can do emergency flashing without any display (note that not all boards support this!), but how often these are not enough? I have too little experience on UEFI motherboards that I could really comment on this, but on one old BIOS motherboard I had to use DOS because it the BIOS tool didn't work well (left me with 64 MiB of usable memory). I know that some people have this thing called Windows which seems to be well supported, but lets assume that one just doesn't have it for whatever reason. It could be just that they don't have a working installation and they can't have it without flashing the (UEFI) BIOS first.
    There is a UEFI feature called "UEFI Capsule" that sends the firmware to the UEFI and has it flash it on its own. Their idea is probably getting this system more standardized and able to work on all devices.
    It's of course supported by Windows https://docs.microsoft.com/en-us/win...pdate-platform
    and there is also a Linux project with tools and its own firmware repository https://fwupd.org/

    If you get your hands on the capsule blob (a *.cab file) you can manually "install" it with the Linux commandline tool. (more like send it to the UEFI and let it do its thing, which is the same on any OS).

    Since this is a standardized UEFI system and not a custom BIOS flashing tool it is less likely to blow up (as any upstream bug will affect anyone, and will be cached fast).

    My Lenovo laptop from 2015 supports it if I check from Linux, and I'm pretty sure the windows-only "firmware upgrade" tool is actually using capsules.

    Comment


    • #32
      Originally posted by starshipeleven View Post
      There is no need for chipset support. The only way to block this at the hardware level is for Intel to remove or lockdown their CPU's 16-bit mode
      Well, then I'm confused as to WTF Intel is actually removing. Again, I don't see mobo vendors taking time/money/effort to add legacy BIOS back in if Intel removes it from their platform.

      Comment


      • #33
        Originally posted by DanL View Post
        Well, then I'm confused as to WTF Intel is actually removing. Again, I don't see mobo vendors taking time/money/effort to add legacy BIOS back in if Intel removes it from their platform.
        Intel is removing the code that gets copy-pasted by vendors to have CSM feature in their firmware.
        And it relies on OEMs not investing a dime in maintaining the feature on their own.
        If you look at hacker blogs you can see that any bug in Intel's platform code released to OEMs is faithfully copied in their firmwares, just to say how much they care.

        As others have said about Clover and SeaBIOS (and I speculated) in first page, as long as Intel does not disable 16-bit mode you can probably "boot" an EFI bootstrapper that pulls on a CSM replacement thing, be it SeaBIOS or whatever.

        But really, if something (hardware or software) does not support UEFI in 2020 it's probably ancient crap that can be put to rest without regrets.

        Comment


        • #34
          ah come on, vBullettin is blocking my post for DanL above.

          Comment


          • #35
            If CSM and OpROM no longer works then vendors of unique devices that don't have boot drivers already in EFI will have to ship EFI drivers. That isn't a big deal.

            Comment


            • #36
              Originally posted by starshipeleven View Post
              CSM does not give me full control over a shit. My OS is still a passenger running under the control of two shit OSes. CSM is a module running on UEFI. It does not disable UEFI, just adds stuff on top to let BIOS applications run.
              That was the whole point of wintel idea I guess. They've started whole saga long ago, probably when MS started demanding digital signatures on drivers, using some stupid excuses. It has been subtle message wintel has decided to lock ppl out of lower levels. Around XP they've also put online activation to show what they're up to. On win7/2008 it became nearly mandatory to merely use computer at all. If it does not phones home in a while, it just breaks. So they could stay in charge of things forever, regardless of what Lusers do. Around Win7 to 8 locks were fully in place, to degree one would struggle real hard to run unsigned kernel level code in Windows. As side effect it has almost killed system-level programming on Windows. Funny enough, MS paid the price, being unable to come with anyhow meaningful filesystems or mobile devices, IoT or basically anything that does not looks like Wintel PC desktop. Around win8 ms has also started demanding secure boot to be in place and active to merely install their OS, using yet another stupid excuses.

              UEFI merely allowed 'em to go further in desired direction. BIOS basically used as dumb boot loader, doing little things on its own. OS eventually takes over in 32 or 64 bit mode, using own drivers, so BIOS isn't really in charge of things after OS kicks in. That's where OEM/Intel/etc mostly lose control on what's going on. That was unacceptable. There was SMM, but this one is rather limited and inconvenient way to backdoor/hijack systems, though it is possible to use it this way (and who knows what SMM handlers in proprietary BIOS things could do?). So now there is ACPI to "abstract" hardware. You no longer go and do what you want with HW. You rather inform "firmware" what you want, and it is up to firmware to know how to do it or even deny you this action, if desired. UEFI also proposes some background services, so there could be some resident code running side-by-side with OS. It could even use its own drivers, and OS is meant to use these to access HW. Of course these drivers are proprietary. And it is so exciting when "BIOS" knows how to deal with net and even manages what your OS could do with net if OS is using UEFI driver. Then there was some ME fun, to be dead sure there IS active running code all the time OS on main CPU can't easily shut down. I could imagine AMD security processors are meant to serve the similar purpose.

              So looking on numerous actions on Wintel side, who would be surprised to see secure boot enforced on nearly all new PCs in few next years? That's what seems to be upcoming.

              None in IT really "wanted" UEFI. It's Intel's pet project.
              Well, BIOS has been obsolete long ago. But unfortunately, cure has proven to be far worse than illness itself. And yeah, wintel has dominated the PC market so they've decided to do whatever pleases them. Though I still do not get where this road leads or why they think it would be good for them or ecosystem. Dumbass consumers mostly move to tablets and phones, where wintel just plain non-existent kind of thing. Computers are left for technically savvy ppl, who are much harder to get goofied. I could imagine it could eventually turn Windows into something marginal.

              Secure Boot per-se isn't as bad. On proper UEFI firmwares the user can add his own keys, so even if they mandate SecureBoot enabled I can still boot what I want.
              Secure Boot is only good, if:
              1) You have source code to ensure everything is fair and there're no backdoors. It never works with real-world UEFI things.
              2) You should have ability to install own root key of trust and eliminate all other keys. This way one becomes true owner of their HW, being able to use own HW as they will, while keeping everyone else out, if desired. Merely "adding own key" is a misnomer - your masters have allowed you to enter, fine, but they have not gave up THEIR access! So it isn't exactly "secure" for you - who knows what would happen with MS keys, what would be signed, etc?

              So UEFI as it implemented on most PCs could rather give false sense of security and then suddenly stab in the back. Devil hides in details and UEFI is big, complicated, and there're many big IFs and hell a lot of details. So overall it just does not looks trustworthy or secure at all. It rather looks and behaves like a mix of backdoors and DRM restrictions, not to mention shady proprietary code. I'm so damn sure companies long known for "engineering passwords" would play fair when it comes to security in huge non-replaceable signed blobs.

              Intel puts the infrastructure in place, but the decision to lockdown or not (i.e. who is good and who is bad) is defined by the OEMs (influenced by Microsoft or not).
              Intel wouldn't be Intel if they wouldn't have left topmost power to self. So there is ME, just in case.

              So yeah, it's shit, but not as bad as you picture.
              I wish it to be true, but somehow there're many small secondary signs. Ever seen mr. Bridgman telling about "DRM sponsored hardware" kind of thing? Just one phrase, but for me it looks pretty clear what's going on. Welcome to iphone-like ecosystem. Apple totally manages their phones and could shut down or disable any phone at will, not to mention removing whatever they want from appstore, making sure there is censorship which is hard to avoid. Say, they've removed VPNs for China, so iphone users would have harder times to fool their dreaded GFW thing. China gov't kindly asked and apple preferred to do it, since they do not want to lose China sales. That's how it works. Sounds exciting, eh?

              Comment


              • #37
                I think it's time to do massive reverse engineering of UEFI BIOSes and contribute to both coreboot and flashrom projects.

                UEFI firmware image viewer and editor. Contribute to maxkalashnikov/UEFITool development by creating an account on GitHub.

                UEFI firmware image viewer and editor. Contribute to LongSoft/UEFITool development by creating an account on GitHub.

                Comment


                • #38
                  Originally posted by starshipeleven View Post
                  None in IT really "wanted" UEFI. It's Intel's pet project.
                  Um. It seems that a lot of of people have NO IDEA how awful it was to program a BIOS before UEFI. Maybe "IT" didn't want something better but BIOS programmers at OEMs sure did!

                  Especially Apple. Once Apple showed everyone else how well it worked they piled on.

                  Comment


                  • #39
                    So...are people going to start migrating off x86 now, or off of Linux in 2020? There are still options now (OpenPOWER / ARM) but if people keep going after the cheapest Wintel / Android DRM-laden solutions now, there won't be any other options in 2020....
                    Last edited by madscientist159; 20 November 2017, 12:48 AM. Reason: Spelling

                    Comment


                    • #40
                      Originally posted by timofonic View Post
                      I think it's time to do massive reverse engineering of UEFI BIOSes and contribute to both coreboot and flashrom projects.

                      UEFI firmware image viewer and editor. Contribute to maxkalashnikov/UEFITool development by creating an account on GitHub.

                      UEFI firmware image viewer and editor. Contribute to LongSoft/UEFITool development by creating an account on GitHub.
                      How do you propose getting your custom firmware (that would take multiple man-years of effort to create, best case) past the lower levels of the DRM currently present on Intel and AMD systems (namely the ME, PSP, etc., implementing technologies like Boot Guard)? Those DRM technologies use strong cryptography that is basically unbreakable (hence why current hacks use other mechanisms like JTAG to break in -- this is useless to the "good guys" but excellent for bad actors).

                      Again, if you're stuck on Windows, you have zero control and privacy anyway, and probably don't (or at least shouldn't) really care much about the hardware enforcing that lack of control. If you're on Linux you have a choice (for now), so why again do Linux users keep embracing the walled garden of x86? Not everything can be hacked past, and eventually the stiff penalties for hacking DRM systems will be enforced more or less universally -- don't take current lax enforcement as a sign of something that will continue, rather look at the recent arrests of various supposed "white hat" hackers for what will eventually happen to anyone trying to break into the x86 walled garden to run unauthorized software. Hic sunt dracones....
                      Last edited by madscientist159; 20 November 2017, 12:56 AM. Reason: Spelling (again)

                      Comment

                      Working...
                      X