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?