[Bug 2084104] Re: UEFI GRUB2 enforces NX even with a non-NX shim

[Mate Kukri]

** Description changed:

- Please also see final comments on
- https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2078307, this whole
- thing stareted there.
+ [ Impact ]
  
- There are two known affected machines currently, one is confirmed to
- correctly be running the non-NX shim and 2.12-5ubuntu5 GRUB.
+ UEFI GRUB2 in Oracular Oriole enforces NX_COMPAT even when used with a
+ non-NX shim.
  
- Despite this, the GRUB on these machines decides to always enforce NX,
- likely because the MokPolicy variable is not being exported exactly as
- GRUB expects.
+ Kernels in Oracular Oriole support NX_COMPAT.
  
- This happens with both Secure Boot enabled and disabled.
+ The impact is limited to failing to chainload other non-NX compatible
+ operating systems from GRUB2.
  
- I have a suspicion that some of the attribute checks in this function
- are not behaving as expected on these firmwares:
- https://git.launchpad.net/~ubuntu-uefi-
- team/grub/+git/ubuntu/tree/debian/patches/nx/efi-Disallow-fallback-to-
- legacy-Linux-loader-when-shim-sa.patch#n22
+ The most common such operating system is Windows 10, most installations
+ of which do not have a NX compatible bootloader according to Microsoft.
  
- The only obvious impact right now is Windows chainloading from GRUB on
- specific affected machines.
+ [ Test Plan ]
+ 
+ 1. Set up (take an existing) machine with Ubuntu Oracular Oriole and
+ Windows 10 in a dual boot configuration.
+ 
+ 2. Verify that `objdump -x /boot/efi/efi/microsoft/boot/bootmgfw.efi`
+ does not show NX_COMPAT under DllCharacteristics.
+ 
+ 3. Verify that Windows 10 fails to boot via the os-prober created GRUB
+ menu entry.
+ 
+ 4. Update grub-efi-amd64-signed to the version from oracular-proposed.
+ 
+ 5. Verify that Windows 10 successfully boots via the os-prober created
+ GRUB menu entry.
+ 
+ 6. Switch to the NX shim using `update-alternatives --set
+ shimx64.efi.signed /usr/lib/shim/shimx64.nx.efi.signed.latest && dpkg-
+ reconfigure shim-signed`
+ 
+ 7. Verify that Windows 10 fails to boot via the os-prober created GRUB
+ menu entry again.
+ 
+ (8. If intending to use this machine switch back to the non-NX shim
+ using: update-alternatives --auto shimx64.efi.signed && dpkg-reconfigure
+ shim-signed)
+ 
+ [ Where problems could occur ]
+ 
+ The patch for this only removes checks, deferring to policy enforced by
+ shim protocol verification that is already in place, thus it should only
+ make more things bootable not less.
+ 
+ When used without shim, existing and this new GRUB2 will only function
+ with Secure Boot disabled, thus no new security problems can arise.
+ 
+ When used with the non-NX shim, the policy will let both non-NX and NX
+ executables through as expected.
+ 
+ When used with the NX shim, the policy will only let NX executables through as expected. Only possible problem here is that if we've have ever signed a pre-LF2 kernel with NX_COMPAT set in DllCharacteristics, such kernel would be let through, then use the non-NX compatible legacy loader, which will lead to crash.
+ The existence of such a kernel is exceedingly unlikely due to the upstream timeline of LF2 and NX supports, but it is a theoretical possibility and hence worth mentioning.
+ 
+ [ Other Info ]
+ 
+ n/a

** Description changed:

  [ Impact ]
  
  UEFI GRUB2 in Oracular Oriole enforces NX_COMPAT even when used with a
  non-NX shim.
  
  Kernels in Oracular Oriole support NX_COMPAT.
  
  The impact is limited to failing to chainload other non-NX compatible
  operating systems from GRUB2.
  
  The most common such operating system is Windows 10, most installations
  of which do not have a NX compatible bootloader according to Microsoft.
  
  [ Test Plan ]
  
- 1. Set up (take an existing) machine with Ubuntu Oracular Oriole and
+ 1. Set up (or take an existing) machine with Ubuntu Oracular Oriole and
  Windows 10 in a dual boot configuration.
  
  2. Verify that `objdump -x /boot/efi/efi/microsoft/boot/bootmgfw.efi`
  does not show NX_COMPAT under DllCharacteristics.
  
  3. Verify that Windows 10 fails to boot via the os-prober created GRUB
  menu entry.
  
  4. Update grub-efi-amd64-signed to the version from oracular-proposed.
  
  5. Verify that Windows 10 successfully boots via the os-prober created
  GRUB menu entry.
  
  6. Switch to the NX shim using `update-alternatives --set
  shimx64.efi.signed /usr/lib/shim/shimx64.nx.efi.signed.latest && dpkg-
  reconfigure shim-signed`
  
  7. Verify that Windows 10 fails to boot via the os-prober created GRUB
  menu entry again.
  
- (8. If intending to use this machine switch back to the non-NX shim
+ (8. If intending to use this machine, switch back to the non-NX shim
  using: update-alternatives --auto shimx64.efi.signed && dpkg-reconfigure
  shim-signed)
  
  [ Where problems could occur ]
  
  The patch for this only removes checks, deferring to policy enforced by
  shim protocol verification that is already in place, thus it should only
  make more things bootable not less.
  
  When used without shim, existing and this new GRUB2 will only function
  with Secure Boot disabled, thus no new security problems can arise.
  
  When used with the non-NX shim, the policy will let both non-NX and NX
  executables through as expected.
  
  When used with the NX shim, the policy will only let NX executables through as expected. Only possible problem here is that if we've have ever signed a pre-LF2 kernel with NX_COMPAT set in DllCharacteristics, such kernel would be let through, then use the non-NX compatible legacy loader, which will lead to crash.
  The existence of such a kernel is exceedingly unlikely due to the upstream timeline of LF2 and NX supports, but it is a theoretical possibility and hence worth mentioning.
  
  [ Other Info ]
  
  n/a

** Description changed:

  [ Impact ]
  
  UEFI GRUB2 in Oracular Oriole enforces NX_COMPAT even when used with a
  non-NX shim.
  
  Kernels in Oracular Oriole support NX_COMPAT.
  
  The impact is limited to failing to chainload other non-NX compatible
  operating systems from GRUB2.
  
  The most common such operating system is Windows 10, most installations
  of which do not have a NX compatible bootloader according to Microsoft.
  
  [ Test Plan ]
  
  1. Set up (or take an existing) machine with Ubuntu Oracular Oriole and
  Windows 10 in a dual boot configuration.
  
  2. Verify that `objdump -x /boot/efi/efi/microsoft/boot/bootmgfw.efi`
  does not show NX_COMPAT under DllCharacteristics.
  
  3. Verify that Windows 10 fails to boot via the os-prober created GRUB
  menu entry.
  
  4. Update grub-efi-amd64-signed to the version from oracular-proposed.
  
  5. Verify that Windows 10 successfully boots via the os-prober created
  GRUB menu entry.
  
  6. Switch to the NX shim using `update-alternatives --set
  shimx64.efi.signed /usr/lib/shim/shimx64.nx.efi.signed.latest && dpkg-
  reconfigure shim-signed`
  
  7. Verify that Windows 10 fails to boot via the os-prober created GRUB
  menu entry again.
  
  (8. If intending to use this machine, switch back to the non-NX shim
  using: update-alternatives --auto shimx64.efi.signed && dpkg-reconfigure
  shim-signed)
  
  [ Where problems could occur ]
  
  The patch for this only removes checks, deferring to policy enforced by
  shim protocol verification that is already in place, thus it should only
  make more things bootable not less.
  
  When used without shim, existing and this new GRUB2 will only function
  with Secure Boot disabled, thus no new security problems can arise.
  
  When used with the non-NX shim, the policy will let both non-NX and NX
  executables through as expected.
  
- When used with the NX shim, the policy will only let NX executables through as expected. Only possible problem here is that if we've have ever signed a pre-LF2 kernel with NX_COMPAT set in DllCharacteristics, such kernel would be let through, then use the non-NX compatible legacy loader, which will lead to crash.
- The existence of such a kernel is exceedingly unlikely due to the upstream timeline of LF2 and NX supports, but it is a theoretical possibility and hence worth mentioning.
+ When used with the NX shim, the policy will only let NX executables
+ through as expected. Only possible problem here is that if we've have
+ ever signed a pre-LF2 kernel with NX_COMPAT set in DllCharacteristics,
+ such kernel would be let through, then use the non-NX compatible legacy
+ loader, which will lead to an inevitable page fault.
+ 
+ The existence of such a kernel is exceedingly unlikely due to the
+ upstream timeline of LF2 and NX supports, but it is a theoretical
+ possibility and hence worth mentioning.
  
  [ Other Info ]
  
  n/a

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/2084104

Title:
  UEFI GRUB2 enforces NX even with a non-NX shim

Status in grub2 package in Ubuntu:
  In Progress

Bug description:
  [ Impact ]

  UEFI GRUB2 in Oracular Oriole enforces NX_COMPAT even when used with a
  non-NX shim.

  Kernels in Oracular Oriole support NX_COMPAT.

  The impact is limited to failing to chainload other non-NX compatible
  operating systems from GRUB2.

  The most common such operating system is Windows 10, most
  installations of which do not have a NX compatible bootloader
  according to Microsoft.

  [ Test Plan ]

  1. Set up (or take an existing) machine with Ubuntu Oracular Oriole
  and Windows 10 in a dual boot configuration.

  2. Verify that `objdump -x /boot/efi/efi/microsoft/boot/bootmgfw.efi`
  does not show NX_COMPAT under DllCharacteristics.

  3. Verify that Windows 10 fails to boot via the os-prober created GRUB
  menu entry.

  4. Update grub-efi-amd64-signed to the version from oracular-proposed.

  5. Verify that Windows 10 successfully boots via the os-prober created
  GRUB menu entry.

  6. Switch to the NX shim using `update-alternatives --set
  shimx64.efi.signed /usr/lib/shim/shimx64.nx.efi.signed.latest && dpkg-
  reconfigure shim-signed`

  7. Verify that Windows 10 fails to boot via the os-prober created GRUB
  menu entry again.

  (8. If intending to use this machine, switch back to the non-NX shim
  using: update-alternatives --auto shimx64.efi.signed && dpkg-
  reconfigure shim-signed)

  [ Where problems could occur ]

  The patch for this only removes checks, deferring to policy enforced
  by shim protocol verification that is already in place, thus it should
  only make more things bootable not less.

  When used without shim, existing and this new GRUB2 will only function
  with Secure Boot disabled, thus no new security problems can arise.

  When used with the non-NX shim, the policy will let both non-NX and NX
  executables through as expected.

  When used with the NX shim, the policy will only let NX executables
  through as expected. Only possible problem here is that if we've have
  ever signed a pre-LF2 kernel with NX_COMPAT set in DllCharacteristics,
  such kernel would be let through, then use the non-NX compatible
  legacy loader, which will lead to an inevitable page fault.

  The existence of such a kernel is exceedingly unlikely due to the
  upstream timeline of LF2 and NX supports, but it is a theoretical
  possibility and hence worth mentioning.

  [ Other Info ]

  n/a

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2084104/+subscriptions