you still haven't understood my post
secure boot is fully "enabled" and "active" but it can be disabled from within the os, that means it isn't secure boot, there's no boundary being enforced as physical access is no longer required, its a security vulnerability
its the same as having a locked door but a button to disable the lock is on both sides of the door, the door lock is engaged, the door lock works, but it doesn't actually keep anybody out
i don't need any help turning on the lock, the lock itself "works", but it serves no purpose because of the implementation
gigabyte has secure boot settings in the "published" hii, which they should not, other oems let you toggle publishing on or off, but it shouldn't be included at all
password protection would mitigate it but their uefi doesn't support password protection, trying to set one i get "Warning: BIOS does not support password feature"?
what i dont know is how to remove a setting from the hii database, how to disable publishing of the hii database, or how to enable password protection of the nvram containing the database
i can do these things on other oem uefi but not gigabyte
update on this:
just got this tested on a similar board before reproducing same result my own, the secure boot settings specifically are blocked and don't actually take effect upon reboot
so i am wrong in that the specific secure boot settings i pointed to as a big obvious issue are actually fine on these boards (no doubt thanks to AMI)
that said, there are other security sensitive settings that can be changed and have similar implications, i can still point them out to gigabyte and I will continue asking them to enable uefi password protection and a toggle for publishing hii resources (similar to asus intel boards)
ofc my ask of any mitigation for this issue in the mean time remains the same while waiting on gigabyte?
secure boot is fully "enabled" and "active" but it can be disabled from within the os, that means it isn't secure boot, there's no boundary being enforced as physical access is no longer required, its a security vulnerability
its the same as having a locked door but a button to disable the lock is on both sides of the door, the door lock is engaged, the door lock works, but it doesn't actually keep anybody out
i don't need any help turning on the lock, the lock itself "works", but it serves no purpose because of the implementation
gigabyte has secure boot settings in the "published" hii, which they should not, other oems let you toggle publishing on or off, but it shouldn't be included at all
password protection would mitigate it but their uefi doesn't support password protection, trying to set one i get "Warning: BIOS does not support password feature"?
what i dont know is how to remove a setting from the hii database, how to disable publishing of the hii database, or how to enable password protection of the nvram containing the database
i can do these things on other oem uefi but not gigabyte
update on this:
just got this tested on a similar board before reproducing same result my own, the secure boot settings specifically are blocked and don't actually take effect upon reboot
so i am wrong in that the specific secure boot settings i pointed to as a big obvious issue are actually fine on these boards (no doubt thanks to AMI)
that said, there are other security sensitive settings that can be changed and have similar implications, i can still point them out to gigabyte and I will continue asking them to enable uefi password protection and a toggle for publishing hii resources (similar to asus intel boards)
ofc my ask of any mitigation for this issue in the mean time remains the same while waiting on gigabyte?
Comment