Opt Green: KDE Eco's New Sustainable Software Project

Posted Jun 3, 2024 14:28 UTC (Mon) by jhe (subscriber, #164815)
In reply to: Opt Green: KDE Eco's New Sustainable Software Project by mjg59
Parent article: Opt Green: KDE Eco's New Sustainable Software Project

It wasn't before SMM. SMM introduced that problem to x86. A PS/2 style BIOS had no security boundary.

ACPI is less a security problem, but it makes your machine unusable with modern distros that rely on ACPI data that is bogus. Think broken power management & suspend.

Xerox 9700 vibes.

Opt Green: KDE Eco's New Sustainable Software Project

Posted Jun 3, 2024 14:46 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

SMM has been around since the 386SL in 1990 - and that's a point in time where the vast majority of people on x86 were running operating systems that had no meaningful security boundaries in any case, so firmware security only became an interesting problem far after SMM was ubiquitous. As far as ACPI goes, the majority of suspend and power management issues we've had for years now have been down to bugs or shortcomings in the Linux driver stack rather than anything in the ACPI tables (suspend actually involves running surprisingly little ACPI code in most cases). It's always been convenient to just blame ACPI, but I've had to deal with more ACPI-related bugs than most people and very few of them have ended up being down to the quality of vendor tables (the only one that springs to mind off-hand is a system that had garbage in the 64-bit register address values, but given it was a 32-bit system with no PAE and so no way to actually have those registers be above 4GB it's almost more surprising that we only saw that once…)

Opt Green: KDE Eco's New Sustainable Software Project

Posted Jun 3, 2024 15:41 UTC (Mon) by farnz (subscriber, #17727) [Link]

Even before SMM, it was an issue. The difference is that "back in the day", you had to check steppings and change ICs physically if you cared about security bugs that could affect the running OS, whereas now you can apply a vendor-supplied patch to fix them. As a consequence of fixes getting simpler to apply, we've started demanding that fixes are provided, rather than just accepting that the hardware is buggy.

And, of course, before the 1990s, when SMM became a thing, it was unusual for an OS to offer any meaningful security boundaries at all - security tended to rely on the fact that if you actively tried to break into the OS, the sysadmin could have your network access withdrawn. For better or worse, that's not the model we work on today; we now assume that attacks are inevitable, and we need to harden our systems against them. Those systems that did have meaningful protection against attackers (military computer systems, for example), took care to use chips with the right steppings so that they were secure.