How (if at all) will this affect installation of non-Microsoft OSs? From Bruce Schneier's Cryptogram newsletter: Microsoft Secure Boot Bug [2023.05.17] Microsoft is currently patching a zero-day Secure-Boot bug. The BlackLotus bootkit is the first-known real-world malware that can bypass Secure Boot protections, allowing for the execution of malicious code before your PC begins loading Windows and its many security protections. Secure Boot has been enabled by default for over a decade on most Windows PCs sold by companies like Dell, Lenovo, HP, Acer, and others. PCs running Windows 11 must have it enabled to meet the software’s system requirements. Microsoft says that the vulnerability can be exploited by an attacker with either physical access to a system or administrator rights on a system. It can affect physical PCs and virtual machines with Secure Boot enabled. That’s important. This is a nasty vulnerability, but it takes some work to exploit it. The problem with the patch is that it breaks backwards compatibility: “...once the fixes have been enabled, your PC will no longer be able to boot from older bootable media that doesn’t include the fixes.” And: Not wanting to suddenly render any users’ systems unbootable, Microsoft will be rolling the update out in phases over the next few months. The initial version of the patch requires substantial user intervention to enable -- you first need to install May’s security updates, then use a five-step process to manually apply and verify a pair of “revocation files” that update your system’s hidden EFI boot partition and your registry. These will make it so that older, vulnerable versions of the bootloader will no longer be trusted by PCs. A second update will follow in July that won’t enable the patch by default but will make it easier to enable. A third update in “first quarter 2024” will enable the fix by default and render older boot media unbootable on all patched Windows PCs. Microsoft says it is “looking for opportunities to accelerate this schedule,” though it’s unclear what that would entail. So it’ll be almost a year before this is completely fixed. Leslie -- Platform: Linux Distribution: openSUSE Leap 15.4 (x86_64)
On 16.06.2023 03:47, J Leslie Turriff wrote:
The problem with the patch is that it breaks backwards compatibility: “...once the fixes have been enabled, your PC will no longer be able to boot from older bootable media that doesn’t include the fixes.”
Well, we have it already with Leap shim patches ... as long as it only blacklists Microsoft own bootloaders, it should not affect Linux users.
On Fri, Jun 16, 2023 at 07:18:49AM +0300, Andrei Borzenkov wrote:
On 16.06.2023 03:47, J Leslie Turriff wrote:
The problem with the patch is that it breaks backwards compatibility: “...once the fixes have been enabled, your PC will no longer be able to boot from older bootable media that doesn’t include the fixes.”
Well, we have it already with Leap shim patches ... as long as it only blacklists Microsoft own bootloaders, it should not affect Linux users.
Yes, the only thing we will do is shipping blacklists for it. Ciao, Marcus
On 16.06.2023 14:24, Marcus Meissner wrote:
On Fri, Jun 16, 2023 at 07:18:49AM +0300, Andrei Borzenkov wrote:
On 16.06.2023 03:47, J Leslie Turriff wrote:
The problem with the patch is that it breaks backwards compatibility: “...once the fixes have been enabled, your PC will no longer be able to boot from older bootable media that doesn’t include the fixes.”
Well, we have it already with Leap shim patches ... as long as it only blacklists Microsoft own bootloaders, it should not affect Linux users.
Yes, the only thing we will do is shipping blacklists for it.
Oops. That is quite different. It means that on dual boot system with Windows and Leap patch for Leap will suddenly blacklist Windows and make it unbootable? This needs quite loud announcement, we already had bad experience with Leap vs. Tumbleweed or Leap patched vs. Leap GA.
On Fri, Jun 16, 2023 at 02:46:04PM +0300, Andrei Borzenkov wrote:
On 16.06.2023 14:24, Marcus Meissner wrote:
On Fri, Jun 16, 2023 at 07:18:49AM +0300, Andrei Borzenkov wrote:
On 16.06.2023 03:47, J Leslie Turriff wrote:
The problem with the patch is that it breaks backwards compatibility: “...once the fixes have been enabled, your PC will no longer be able to boot from older bootable media that doesn’t include the fixes.”
Well, we have it already with Leap shim patches ... as long as it only blacklists Microsoft own bootloaders, it should not affect Linux users.
Yes, the only thing we will do is shipping blacklists for it.
Oops. That is quite different. It means that on dual boot system with Windows and Leap patch for Leap will suddenly blacklist Windows and make it unbootable? This needs quite loud announcement, we already had bad experience with Leap vs. Tumbleweed or Leap patched vs. Leap GA.
Depends on what Microsoft requires from the shim team. The UEFI secure boot consortium is shared, you cannot split it into Windows or Non-Windows worlds. Ciao, Marcus
On 16.06.2023 14:51, Marcus Meissner wrote:
On Fri, Jun 16, 2023 at 02:46:04PM +0300, Andrei Borzenkov wrote:
On 16.06.2023 14:24, Marcus Meissner wrote:
On Fri, Jun 16, 2023 at 07:18:49AM +0300, Andrei Borzenkov wrote:
On 16.06.2023 03:47, J Leslie Turriff wrote:
The problem with the patch is that it breaks backwards compatibility: “...once the fixes have been enabled, your PC will no longer be able to boot from older bootable media that doesn’t include the fixes.”
Well, we have it already with Leap shim patches ... as long as it only blacklists Microsoft own bootloaders, it should not affect Linux users.
Yes, the only thing we will do is shipping blacklists for it.
Oops. That is quite different. It means that on dual boot system with Windows and Leap patch for Leap will suddenly blacklist Windows and make it unbootable? This needs quite loud announcement, we already had bad experience with Leap vs. Tumbleweed or Leap patched vs. Leap GA.
Depends on what Microsoft requires from the shim team.
The UEFI secure boot consortium is shared, you cannot split it into Windows or Non-Windows worlds.
Does Windows carry SBAT blacklists for Linux grub2? I am really curious, I could not find any information about SBAT usage in Windows.
On Fri, Jun 16, 2023 at 02:56:05PM +0300, Andrei Borzenkov wrote:
On 16.06.2023 14:51, Marcus Meissner wrote:
On Fri, Jun 16, 2023 at 02:46:04PM +0300, Andrei Borzenkov wrote:
On 16.06.2023 14:24, Marcus Meissner wrote:
On Fri, Jun 16, 2023 at 07:18:49AM +0300, Andrei Borzenkov wrote:
On 16.06.2023 03:47, J Leslie Turriff wrote:
The problem with the patch is that it breaks backwards compatibility: “...once the fixes have been enabled, your PC will no longer be able to boot from older bootable media that doesn’t include the fixes.”
Well, we have it already with Leap shim patches ... as long as it only blacklists Microsoft own bootloaders, it should not affect Linux users.
Yes, the only thing we will do is shipping blacklists for it.
Oops. That is quite different. It means that on dual boot system with Windows and Leap patch for Leap will suddenly blacklist Windows and make it unbootable? This needs quite loud announcement, we already had bad experience with Leap vs. Tumbleweed or Leap patched vs. Leap GA.
Depends on what Microsoft requires from the shim team.
The UEFI secure boot consortium is shared, you cannot split it into Windows or Non-Windows worlds.
Does Windows carry SBAT blacklists for Linux grub2? I am really curious, I could not find any information about SBAT usage in Windows.
No, SBAT handling is entirely Linux / shim side. (And yes, this is generational blacklisting on the shim side of the eco system.) Ciao, Marcus
On 16.06.2023 14:57, Marcus Meissner wrote:
On Fri, Jun 16, 2023 at 02:56:05PM +0300, Andrei Borzenkov wrote:
On 16.06.2023 14:51, Marcus Meissner wrote:
On Fri, Jun 16, 2023 at 02:46:04PM +0300, Andrei Borzenkov wrote:
On 16.06.2023 14:24, Marcus Meissner wrote:
On Fri, Jun 16, 2023 at 07:18:49AM +0300, Andrei Borzenkov wrote:
On 16.06.2023 03:47, J Leslie Turriff wrote: > The problem with the patch is that it breaks backwards compatibility: “...once > the fixes have been enabled, your PC will no longer be able to boot from older > bootable media that doesn’t include the fixes.”
Well, we have it already with Leap shim patches ... as long as it only blacklists Microsoft own bootloaders, it should not affect Linux users.
Yes, the only thing we will do is shipping blacklists for it.
Oops. That is quite different. It means that on dual boot system with Windows and Leap patch for Leap will suddenly blacklist Windows and make it unbootable? This needs quite loud announcement, we already had bad experience with Leap vs. Tumbleweed or Leap patched vs. Leap GA.
Depends on what Microsoft requires from the shim team.
The UEFI secure boot consortium is shared, you cannot split it into Windows or Non-Windows worlds.
Does Windows carry SBAT blacklists for Linux grub2? I am really curious, I could not find any information about SBAT usage in Windows.
No, SBAT handling is entirely Linux / shim side. (And yes, this is generational blacklisting on the shim side of the eco system.)
But how can shim blacklist Microsoft bootloader if Microsoft bootloader does not use SBAT? SBAT relies on programs actively refusing to run if they are below required level. I am sorry for nagging, but I really try to understand. Alternative is to use the legacy approach to add hashes to dbx but that does not require any cooperation from shim. Or do you mean that shim will add blacklisted hashes to dbx?
On Sat, Jun 17, 2023 at 04:17:07PM +0300, Andrei Borzenkov wrote:
On 16.06.2023 14:57, Marcus Meissner wrote:
On Fri, Jun 16, 2023 at 02:56:05PM +0300, Andrei Borzenkov wrote:
On 16.06.2023 14:51, Marcus Meissner wrote:
On Fri, Jun 16, 2023 at 02:46:04PM +0300, Andrei Borzenkov wrote:
On 16.06.2023 14:24, Marcus Meissner wrote:
On Fri, Jun 16, 2023 at 07:18:49AM +0300, Andrei Borzenkov wrote: > On 16.06.2023 03:47, J Leslie Turriff wrote: > > The problem with the patch is that it breaks backwards compatibility: “...once > > the fixes have been enabled, your PC will no longer be able to boot from older > > bootable media that doesn’t include the fixes.” > > Well, we have it already with Leap shim patches ... as long as it only > blacklists Microsoft own bootloaders, it should not affect Linux users.
Yes, the only thing we will do is shipping blacklists for it.
Oops. That is quite different. It means that on dual boot system with Windows and Leap patch for Leap will suddenly blacklist Windows and make it unbootable? This needs quite loud announcement, we already had bad experience with Leap vs. Tumbleweed or Leap patched vs. Leap GA.
Depends on what Microsoft requires from the shim team.
The UEFI secure boot consortium is shared, you cannot split it into Windows or Non-Windows worlds.
Does Windows carry SBAT blacklists for Linux grub2? I am really curious, I could not find any information about SBAT usage in Windows.
No, SBAT handling is entirely Linux / shim side. (And yes, this is generational blacklisting on the shim side of the eco system.)
But how can shim blacklist Microsoft bootloader if Microsoft bootloader does not use SBAT? SBAT relies on programs actively refusing to run if they are below required level. I am sorry for nagging, but I really try to understand.
Alternative is to use the legacy approach to add hashes to dbx but that does not require any cooperation from shim.
Yes, this would usually be done. shim also honors dbx, it could embed "vendor dbx" files too. (e.g. non UEFI stored DBX).
Or do you mean that shim will add blacklisted hashes to dbx?
Yes, via the dbx files. However there is limited DBX space in the UEFI variables, which will run full at some point. That said, lets see what happens. Ciao, Marcus
participants (3)
-
Andrei Borzenkov -
J Leslie Turriff -
Marcus Meissner