Announcement

Collapse
No announcement yet.

EFI In Linux 4.14 Will Better Handle Rebooting Of Buggy Systems

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

  • EFI In Linux 4.14 Will Better Handle Rebooting Of Buggy Systems

    Phoronix: EFI In Linux 4.14 Will Better Handle Rebooting Of Buggy Systems

    There are a few notable EFI fixes to find for the in-development Linux 4.14 kernel...

    http://www.phoronix.com/scan.php?pag...14-EFI-Changes

  • #2
    I'm not a programmer, so I could well be misinterpreting this, but it seems to me like EFI treats programmers coding for it like they are themselves malicious. WTF?

    Comment


    • #3
      Originally posted by duby229 View Post
      I'm not a programmer, so I could well be misinterpreting this, but it seems to me like EFI treats programmers coding for it like they are themselves malicious. WTF?
      Of course. TPM/SecureBoot/... is all about not trusting you, the product, or more recently the training data for corporate AI.

      Comment


      • #4
        Originally posted by duby229 View Post
        I'm not a programmer, so I could well be misinterpreting this, but it seems to me like EFI treats programmers coding for it like they are themselves malicious. WTF?
        It's an excuse to lock things down and prevent alternate implementations, as far as I'm concerned.

        Comment


        • #5
          Originally posted by duby229 View Post
          I'm not a programmer, so I could well be misinterpreting this, but it seems to me like EFI treats programmers coding for it like they are themselves malicious. WTF?
          You are misinterpreting this.

          This article talks about:

          -a workaround to shut down properly a device with EFI firmware when the EFI does not work properly with the "shut down call"

          -a call to EFI firmware that tells it to reboot hardware AND to wipe ram to make sure that any secret things you were doing in RAM get wiped and can't be read from a ram dump done after a reboot.

          I don't see anything bad in either thing.
          Last edited by starshipeleven; 09-05-2017, 10:12 AM.

          Comment


          • #6
            Originally posted by Maxim Levitsky View Post
            Of course. TPM/SecureBoot/... is all about not trusting you, the product, or more recently the training data for corporate AI.
            You mean Management Engine perhaps?
            TPM is just a storage for hardware keys, SecureBoot can import your own keys too if the OEM didn't close it down.

            Comment


            • #7
              UEFI, TCPA/TPM, it's all a pile of steaming digital restriction and possible backdoor + bloat crap. Intel was also not very Coreboot friendly (in nice terms) until they had finally pushed this crapload of UEFI to the masses. Maybe the old BIOS wasn't perfect. But what was it supposed to do? Just boot the computer, and give the user a minimal setup to configure some interfaces and a media where the OS was supposed to be. Then check all attached data carriers for a magic string of boot record and execute that one. Give control to the bootloader who's doing next steps then.
              All that could be done with a few KiB of code - and nobody needed a network stack... or digital restriction management on a FW level.
              An all that stuff runs with maxed privileges, on ring < 0. Unaware for any OS or a possible anti-malware solution.

              Besides, yes, we had crappy ACPI tables all the way back since ACPI was created (MS/intel... no surprise). But I hardly have seen old BIOS-based machines messing up a reboot or bricking if you wrote variables that were supposed to be written (bricked Samsung(?) netbooks anyone?).

              The kernel changes sound good, nevertheless, and overwriting memory on shutdown / reboot is generally a reasonable idea.
              Stop TCPA, stupid software patents and corrupt politicians!

              Comment


              • #8
                Originally posted by Adarion View Post
                UEFI, TCPA/TPM, it's all a pile of steaming digital restriction and possible backdoor + bloat crap.


                Comment


                • #9
                  Hans de Goede noted that some Bay Trail devices are not behaving correctly and warranty this transparent fallback during the power-off process.
                  lol now I'm wondering, is there an even worse hardware than Bay Trail tablets? How could they have released such a crap, did they even test it?

                  Comment


                  • #10
                    Originally posted by Adarion View Post
                    and nobody needed a network stack... or digital restriction management on a FW level.
                    the music & hollywood companies & sutff that pay intel billions to implement this kind of stuff certainly do need them.

                    See http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html

                    Comment

                    Working...
                    X