"Microsoft did this by pushing a Windows Update that updated the SBAT variable to indicate that known-vulnerable versions of grub shouldn't be allowed to boot on those systems."
And:
"Linux updates are also capable of rendering Windows unbootable"
Does that also means that malware (with kernel access) is capable of increasing the SBAT variable as well and brick the computer if UEFI secure boot cannot be deactivated, or at least force users to deactivate UEFI secure boot? Or is that request signed somehow? If so who can sign it? And ideally who do you think should do that update? The boot firmware vendor?
As I understand, another issue here is the problem of running untrusted applications combined with drivers / OS components with bad code quality.
That tend to be more the case on Windows (or Android) as users are expected to download and run applications from whatever place. And then this untrusted code can exploit bugs inside the OS that weren't fixed (for instance by combining together lower priority bugs that weren't fixed because that costs money (or because users can't update in the case of Android)).
And so in a case like that it makes sense to try to mitigate the issue by using more trusted components with a smaller attack surface to secure the rest of the computer (such as HVCI, the Management Engine, etc) and so as I understand in this context secure boot makes perfect sense.
This issue is also present on GNU/Linux in a lesser extent: if users also run untrusted applications and use OS components with known security issues (like Xorg) or bad drivers (like out of tree drivers for WiFi, GPU, etc) then the untrusted software can try to do privilege escalation and compromise the computer in the most permanent way possible.
The untrusted software could be random software downloaded from the Internet, or even software provided directly by the author that manages to escape a sanbox somehow (it could be JavaScript, appimage/docker/etc) as the only difficult part would be to find a sandbox escape vulnerability.
So the problem here is if users run GNU/Linux without untrusted applications, then we have 2 completely different security models on the same computer, and without Windows and untrusted applications in GNU/Linux, secure boot might make less sense if the user threat model doesn't need that extra protection.
Re: Why is it up to Microsoft to take care of MY computer's security?
With:
"Microsoft did this by pushing a Windows Update that updated the SBAT variable to indicate that known-vulnerable versions of grub shouldn't be allowed to boot on those systems."
And: "Linux updates are also capable of rendering Windows unbootable"
Does that also means that malware (with kernel access) is capable of increasing the SBAT variable as well and brick the computer if UEFI secure boot cannot be deactivated, or at least force users to deactivate UEFI secure boot? Or is that request signed somehow? If so who can sign it? And ideally who do you think should do that update? The boot firmware vendor?
As I understand, another issue here is the problem of running untrusted applications combined with drivers / OS components with bad code quality.
That tend to be more the case on Windows (or Android) as users are expected to download and run applications from whatever place. And then this untrusted code can exploit bugs inside the OS that weren't fixed (for instance by combining together lower priority bugs that weren't fixed because that costs money (or because users can't update in the case of Android)).
And so in a case like that it makes sense to try to mitigate the issue by using more trusted components with a smaller attack surface to secure the rest of the computer (such as HVCI, the Management Engine, etc) and so as I understand in this context secure boot makes perfect sense.
This issue is also present on GNU/Linux in a lesser extent: if users also run untrusted applications and use OS components with known security issues (like Xorg) or bad drivers (like out of tree drivers for WiFi, GPU, etc) then the untrusted software can try to do privilege escalation and compromise the computer in the most permanent way possible.
The untrusted software could be random software downloaded from the Internet, or even software provided directly by the author that manages to escape a sanbox somehow (it could be JavaScript, appimage/docker/etc) as the only difficult part would be to find a sandbox escape vulnerability.
So the problem here is if users run GNU/Linux without untrusted applications, then we have 2 completely different security models on the same computer, and without Windows and untrusted applications in GNU/Linux, secure boot might make less sense if the user threat model doesn't need that extra protection.
Denis.