Intel Readies "PFRUT" For Linux 5.17 To Allow Updating System Firmware Without Rebooting

[phoronix]

Phoronix: Intel Readies "PFRUT" For Linux 5.17 To Allow Updating System Firmware Without Rebooting

Intel open-source engineers have prepared "PFRUT" support for Platform Firmware Runtime Updates for allowing (U)EFI capsule updates to be performed on capable systems without rebooting the system in order to eliminate downtime...

https://www.phoronix.com/scan.php?page=news_item&px=Intel-PFRUT-Linux-5.17

[tildearrow]

Here is a list of consumer retail motherboards capable of this on Linux:

[tildearrow]

Also, "telemetry"? Telemetry as in something very useful like sensor data (temperatures, fan speeds, voltages, case intrusion detection, etc.), or something shady like being able to read out the system's memory/sending network packets without OS visibility?

[DanL]

Here is a list of consumer retail motherboards capable of this on Linux:

Well, then, obviously, "consumer retail" is not the focus of this project...

[davidhendricks]

Intel and Microsoft gave a presentation about this a while back at the 2019 OCP Summit: https://146a55aca6f00848c565-a763552...475346580c.pdf

tl;dr: The idea here is to enable UEFI to write a staged copy somewhere that will be activated next time the system is booted, rather than the typical UEFI "capsule" update mechanism which updates the firmware as part of the boot process itself. There absolutely is a reboot and downtime involved here, and the datasheets specify it in more detail. The wording "without rebooting" and "eliminate downtime" used in the article is simply wrong.

That said, the wording of the Kconfig option in the patch is technically correct in that *some* components can be updated at runtime. Microcode is a good example. Perhaps they plan to eliminate the ability for Linux to update microcode on its own the way it does today and require a trip through closed-source UEFI code instead.

[CommunityMember]

That said, the wording of the Kconfig option in the patch is technically correct in that *some* components can be updated at runtime.

In the networking world, where uptime is often paramount at the core of the core, updating firmware (for some components) in real time, at run time, has been possible for quite some time. Some updates required a momentary quiescence of a linecard/port to swap over to the updated firmware, and some required failover to an alternative pathing during the update. One can easily imagine a similar situation for CPUs (for "real time" updates, quiescent instruction processing, flush caches, swap to the new firmware, restart processing), although it may take some time to get to that stage. And for larger (or more complex) updates, migrating a physical CPU offline/online (logically no different than OIR) is certainly a possibility.

And yes, this is likely server class only, as one doesn't have the necessary redundancy in consumer priced equipment, and while there are likely a handful of consumers willing to pay for enterprise servers as their desktop, the vast majority of the consumer class are not going to be willing to pay for the capability to avoid a reboot a few times a year.

[jeoshua]

Perhaps they plan to eliminate the ability for Linux to update microcode on its own the way it does today and require a trip through closed-source UEFI code instead.

This took a turn. You sound like a war veteran who's seen some shit.

[davidhendricks]

In the networking world, where uptime is often paramount at the core of the core, updating firmware (for some components) in real time, at run time, has been possible for quite some time. Some updates required a momentary quiescence of a linecard/port to swap over to the updated firmware, and some required failover to an alternative pathing during the update. One can easily imagine a similar situation for CPUs (for "real time" updates, quiescent instruction processing, flush caches, swap to the new firmware, restart processing), although it may take some time to get to that stage. And for larger (or more complex) updates, migrating a physical CPU offline/online (logically no different than OIR) is certainly a possibility.

And yes, this is likely server class only, as one doesn't have the necessary redundancy in consumer priced equipment, and while there are likely a handful of consumers willing to pay for enterprise servers as their desktop, the vast majority of the consumer class are not going to be willing to pay for the capability to avoid a reboot a few times a year.

True, but this isn't online CPU replacement, nor is it updating firmware on a peripheral. What you describe is great, it just isn't what the article is talking about.

[MrCal]

Interesting to compare Intel and AMD in regards to focus on technologies surrounding their CPUs, e.g. drivers, chipset, utils, Linux support etc. AMD still haven't understood the importance of features and stability of the WHOLE system not just the CPU, that's why Intel can still charge a premium price for their CPUs and still sell many times more, even for CPU's that a slower. That's why businesses choose Intel and not AMD, the risk of "trouble" is just not worse it. I know AMD is taking market shares, but Intel is still way ahead and will keep being so until AMD start to understand it's not all about the CPU isolated. There are always exceptions, e.g. AMD was first with PCIe4, has less CPU vulnerabilities, but overall, people still trust the Intel brand more than AMD for their vital infrastructure, it's another story in the consumer market.

[CochainComplex]

Interesting to compare Intel and AMD in regards to focus on technologies surrounding their CPUs, e.g. drivers, chipset, utils, Linux support etc. AMD still haven't understood the importance of features and stability of the WHOLE system not just the CPU, that's why Intel can still charge a premium price for their CPUs and still sell many times more, even for CPU's that a slower. That's why businesses choose Intel and not AMD, the risk of "trouble" is just not worse it. I know AMD is taking market shares, but Intel is still way ahead and will keep being so until AMD start to understand it's not all about the CPU isolated. There are always exceptions, e.g. AMD was first with PCIe4, has less CPU vulnerabilities, but overall, people still trust the Intel brand more than AMD for their vital infrastructure, it's another store in the consumer market.

You are right but in AMD's defence just a few years ago their companies strategy was to "just survive" with their limited resources. The things we are talking here are relevant but not if you are about to go "all in" for your next chip design - IPC performances and corecounts are the attention drivers across the whole industry.
Luckily they have turned everything to the positive side. And yes to prosper now your point has to be taken into consideration.