EFI In Linux 4.14 Will Better Handle Rebooting Of Buggy Systems

[phoronix]

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?page=news_item&px=Linux-4.14-EFI-Changes

[duby229]

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?

[Maxim Levitsky]

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.

[bug77]

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.

[starshipeleven]

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.

[starshipeleven]

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.

[Adarion]

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.

[starshipeleven]

UEFI, TCPA/TPM, it's all a pile of steaming digital restriction and possible backdoor + bloat crap.

[Hi-Angel]

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?

[doom_Oo7]

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