Hacker News Reader

Comment by jesprenj | Hacker News Reader

As far as I understand, this only affects Windows installations. The update process is executed from Windows and not from motherboard's code itself. The motherboard's code only installs a Windows executable on your hard drive.

View on HN

I don't see what would stop it from downloading and running an update that would work with Linux, it's that Gigabyte has little financial incentive to create a Linux updater. A malicious actor may, though probably doesn't given Gigabyte's target market.

WPBT is explicitly not supported by Linux kernel. On windows side it is handled by (I may be mistaken, haven't verified that) `wpbbin.exe` binary.

https://docs.kernel.org/arm64/acpi_object_usage.html says:

> Microsoft only table, will not be supported.

(I know, it's for arm64, but there seems to be no other docs)

But, you can use your Linux kernel to see what's inside your motherboard. Check /sys/firmware/acpi/tables/WPBT, if you have one.

source: https://michlstechblog.info/blog/windows-identify-a-wpbt-bin...

Sure, but if it's arbitrarily throwing things into the ESP and having them be run on boot, they presumably could do the same thing with Linux. Maybe secure boot would stop it, otherwise I don't see why it couldn't add another initrd to your boot config.

It isn't touching your disk at all. It's just providing an executable in a specific ACPI table that Windows explicitly supports running code from for the purpose of installing OEM-provided software.

I was wrong on what exactly it was doing, but GRUB seems to have some level of support for doing the same thing. https://www.gnu.org/software/grub/manual/grub/html_node/acpi...

Reply on news.ycombinator.com