3 ms·

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 motherb

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.

deleted 3y ago
[deleted]
boomboomsubban 3y ago
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.
- hiciu 3y ago
  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 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-binary-in-biosuefi/ https://michlstechblog.info/blog/windows-identify-a-wpbt-bin...
  - boomboomsubban 3y ago
    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.
    - Nextgrid 3y ago
      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.
      - boomboomsubban 3y ago
        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.html https://www.gnu.org/software/grub/manual/grub/html_node/acpi...
deleted 3y ago
[deleted]

deleted 3y ago

[deleted]

boomboomsubban 3y ago

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.

hiciu 3y ago
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 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-binary-in-biosuefi/ https://michlstechblog.info/blog/windows-identify-a-wpbt-bin...
- boomboomsubban 3y ago
  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.
  - Nextgrid 3y ago
    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.
    - boomboomsubban 3y ago
      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.html https://www.gnu.org/software/grub/manual/grub/html_node/acpi...

deleted 3y ago

[deleted]