Last year, several security vulnerabilities were discovered, making it difficult for system administrators to patch the systems without downtime quickly.
What if some improvements can be made to update some critical components for security/performance improvements without rebooting a system?
Intel aims to achieve that with its new PFRUT (Platform Firmware Runtime Update and Telemetry) driver.
Intel Plans to Make PFRUT Available With Linux Kernel 5.17
While Linux Kernel 5.16 is due later this weekend, Intel aims to merge this new addition with the upcoming Linux Kernel 5.17 stable release.
But, what exactly is it?
With PFRUT driver, specific components (or the system firmware) can be updated while the system is running without needing to reboot.
Initially, Intel preferred to call it a “Seamless Update” solution. However, with the recent commit for Linux Kernel added to the Linux power management’s “linux-next” branch, they might be sticking to a vendor-neutral name, pfrut_driver.
If you are curious, the “linux-next” branch means that those changes will make their way to the next Linux Kernel 5.17 stable release.
In technical terms, the commit explains the change as follows:
The user is expected to provide the EFI capsule, and pass it to the driver by writing the capsule to a device special file. The capsule is transferred by the driver to the platform firmware with the help of an ACPI _DSM method under the special ACPI Platform Firmware Runtime Update device (INTC1080), and the actual firmware update is carried out by the low-level Management Mode code in the platform firmware
This should eliminate any downtime, as one would typically expect with an essential update to firmware addressing any security and performance improvements. And, system firmware updates can be easily applied directly through the operating system (Linux, here).
The telemetry part of the driver exists to “retrieve log messages from MM for monitoring
and the root cause of issues,” as highlighted in one of the PDFs detailing how this works.
Note that this is only possible with a Linux system and an Intel chip on board.
The addition of this ability should come in incredibly handy, considering it is not ideal to wait for a task to complete when you need to patch the system firmware to defend against a security issue.
Is This for Linux Desktop or Server?
Primarily, the improvement is tailored to benefit server-specific hardware.
The official Intel documentation states it is meant for systems with high service level agreements (SLAs) requiring a minimal number of reboots.
However, this should be useful for a specific group of desktop users with enterprise-grade systems.
While this may not be something essential for desktop Linux distros, it could be an exciting start to something that improves the user experience. Specifically for users keen to keep their system firmware updated without severe interruptions to their active work.
This should also introduce the possibility of more types of updates that can be handled by the operating system instead of the motherboard when it comes to BIOS or UEFI.
Not just limited to the support for Linux desktop users, one would need to have server-grade hardware configured for your desktop.
This is limited to Linux systems, but this should also be possible for Windows and other operating systems soon.
What do you think about this change introduced by Intel? Do you think it is a significant improvement to how system firmware updates are being handled?
Feel free to share your thoughts in the comments below.
Here's why you should opt for It's FOSS Plus Membership
- Even the biggest players in the Linux world don't care about desktop Linux users. We do.
- We don't put content behind paywall. Your support keeps it open for everyone. Think of it like 'pay it forward'.
- Don't like ads? With the Plus membership, you get an ad-free reading experience.
- When millions of AI-generated content is being published daily, you read and learn from real human Linux users.
- It costs just $2 a month, less than the cost of your favorite burger.
