- Nov 29, 2021
-
-
Colin Watson authored
minilzo fails to build on a number of Debian release architectures (armel, mips64el, mipsel, ppc64el) with errors such as: ../../grub-core/lib/minilzo/minilzo.c: In function 'lzo_memops_get_le16': ../../grub-core/lib/minilzo/minilzo.c:3479:11: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] 3479 | * (lzo_memops_TU2p) (lzo_memops_TU0p) (dd) = * (const lzo_memops_TU2p) (const lzo_memops_TU0p) (ss); \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../grub-core/lib/minilzo/minilzo.c:3530:5: note: in expansion of macro 'LZO_MEMOPS_COPY2' 3530 | LZO_MEMOPS_COPY2(&v, ss); | ^~~~~~~~~~~~~~~~ The latest upstream version is 2.10, so updating to it seems like a good idea on general principles, and it fixes builds on all the above architectures. The update procedure documented in the GRUB Developers Manual worked; I just updated the version numbers to make it clear that it's been executed recently. Signed-off-by:
Colin Watson <cjwatson@debian.org> Forwarded: https://lists.gnu.org/archive/html/grub-devel/2021-11/msg00095.html Last-Update: 2021-11-29 Patch-Name: minilzo-2.10.patch
-
- Sep 27, 2021
-
-
Colin Watson authored
This allows the controversial "recovery mode" text to be customised. Bug-Ubuntu: https://bugs.launchpad.net/bugs/1240360 Forwarded: no Last-Update: 2013-12-25 Patch-Name: mkconfig-recovery-title.patch
-
Colin Watson authored
If other operating systems are installed, then automatically unhide the menu. Otherwise, if GRUB_HIDDEN_TIMEOUT is 0, then use keystatus if available to check whether Shift is pressed. If it is, show the menu, otherwise boot immediately. If keystatus is not available, then fall back to a short delay interruptible with Escape. This may or may not remain Ubuntu-specific, although it's not obviously wanted upstream. It implements a requirement of https://wiki.ubuntu.com/DesktopExperienceTeam/KarmicBootExperienceDesignSpec#Bootloader. If the previous boot failed (defined as failing to get to the end of one of the normal runlevels), then show the boot menu regardless. Author: Richard Laager <rlaager@wiktel.com> Author: Robie Basak <robie.basak@ubuntu.com> Forwarded: no Last-Update: 2015-09-04 Patch-Name: quick-boot.patch
-
- Sep 24, 2021
-
-
Colin Watson authored
This allows the controversial "recovery mode" text to be customised. Bug-Ubuntu: https://bugs.launchpad.net/bugs/1240360 Forwarded: no Last-Update: 2013-12-25 Patch-Name: mkconfig-recovery-title.patch
-
Colin Watson authored
If other operating systems are installed, then automatically unhide the menu. Otherwise, if GRUB_HIDDEN_TIMEOUT is 0, then use keystatus if available to check whether Shift is pressed. If it is, show the menu, otherwise boot immediately. If keystatus is not available, then fall back to a short delay interruptible with Escape. This may or may not remain Ubuntu-specific, although it's not obviously wanted upstream. It implements a requirement of https://wiki.ubuntu.com/DesktopExperienceTeam/KarmicBootExperienceDesignSpec#Bootloader. If the previous boot failed (defined as failing to get to the end of one of the normal runlevels), then show the boot menu regardless. Author: Richard Laager <rlaager@wiktel.com> Author: Robie Basak <robie.basak@ubuntu.com> Forwarded: no Last-Update: 2015-09-04 Patch-Name: quick-boot.patch
-
Colin Watson authored
This is kind of a mess, requiring lots of OS-specific code to iterate over all possible devices. However, we use it in a number of scripts to discover devices and reimplementing those in terms of something else would be very complicated. Author: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Forwarded: no Last-Update: 2021-09-24 Patch-Name: restore-mkdevicemap.patch
-
- Jun 13, 2021
-
-
Peter Jones authored
Add a --sbat option to the grub-mkimage tool which allows us to import an SBAT metadata formatted as a CSV file into a .sbat section of the EFI binary. Signed-off-by:
Peter Jones <pjones@redhat.com> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Patch-Name: 2021-02-security/107-util-mkimage-Add-an-option-to-import-SBAT-metadata-into-a-.sbat-section.patch
-
Javier Martinez Canillas authored
The command is not present in the docs/grub.texi user documentation. Reported-by:
Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Patch-Name: 2021-02-security/013-docs-Document-the-cutmem-command.patch
-
Javier Martinez Canillas authored
There are some more commands that should be restricted when the GRUB is locked down. Following is the list of commands and reasons to restrict: * fakebios: creates BIOS-like structures for backward compatibility with existing OSes. This should not be allowed when locked down. * loadbios: reads a BIOS dump from storage and loads it. This action should not be allowed when locked down. * devicetree: loads a Device Tree blob and passes it to the OS. It replaces any Device Tree provided by the firmware. This also should not be allowed when locked down. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Patch-Name: 2021-02-security/008-commands-Restrict-commands-that-can-load-BIOS-or-DT-blobs-when-locked-down.patch
-
Javier Martinez Canillas authored
The cutmem and badram commands can be used to remove EFI memory regions and potentially disable the UEFI Secure Boot. Prevent the commands to be registered if the GRUB is locked down. Fixes: CVE-2020-27779 Reported-by:
Teddy Reed <teddy.reed@gmail.com> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Patch-Name: 2021-02-security/007-mmap-Don-t-register-cutmem-and-badram-commands-when-lockdown-is-enforced.patch
-
Javier Martinez Canillas authored
The command is not allowed when lockdown is enforced. Otherwise an attacker can instruct the GRUB to load an SSDT table to overwrite the kernel lockdown configuration and later load and execute unsigned code. Fixes: CVE-2020-14372 Reported-by:
Máté Kukri <km@mkukri.xyz> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Patch-Name: 2021-02-security/006-acpi-Don-t-register-the-acpi-command-when-locked-down.patch
-
Javier Martinez Canillas authored
Now the GRUB can check if it has been locked down and this can be used to prevent executing commands that can be utilized to circumvent the UEFI Secure Boot mechanisms. So, instead of hardcoding a list of modules that have to be disabled, prevent the usage of commands that can be dangerous. This not only allows the commands to be disabled on other platforms, but also properly separate the concerns. Since the shim_lock verifier logic should be only about preventing to run untrusted binaries and not about defining these kind of policies. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Patch-Name: 2021-02-security/005-efi-Use-grub_is_lockdown-instead-of-hardcoding-a-disabled-modules-list.patch
-
Javier Martinez Canillas authored
It may be useful for scripts to determine whether the GRUB is locked down or not. Add the lockdown variable which is set to "y" when the GRUB is locked down. Suggested-by:
Dimitri John Ledkov <xnox@ubuntu.com> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Patch-Name: 2021-02-security/003-kern-lockdown-Set-a-variable-if-the-GRUB-is-locked-down.patch
-
Javier Martinez Canillas authored
When the GRUB starts on a secure boot platform, some commands can be used to subvert the protections provided by the verification mechanism and could lead to booting untrusted system. To prevent that situation, allow GRUB to be locked down. That way the code may check if GRUB has been locked down and further restrict the commands that are registered or what subset of their functionality could be used. The lockdown support adds the following components: * The grub_lockdown() function which can be used to lockdown GRUB if, e.g., UEFI Secure Boot is enabled. * The grub_is_lockdown() function which can be used to check if the GRUB was locked down. * A verifier that flags OS kernels, the GRUB modules, Device Trees and ACPI tables as GRUB_VERIFY_FLAGS_DEFER_AUTH to defer verification to other verifiers. These files are only successfully verified if another registered verifier returns success. Otherwise, the whole verification process fails. For example, PE/COFF binaries verification can be done by the shim_lock verifier which validates the signatures using the shim_lock protocol. However, the verification is not deferred directly to the shim_lock verifier. The shim_lock verifier is hooked into the verification process instead. * A set of grub_{command,extcmd}_lockdown functions that can be used by code registering command handlers, to only register unsafe commands if the GRUB has not been locked down. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Patch-Name: 2021-02-security/002-kern-Add-lockdown-support.patch
-
- May 10, 2021
-
-
Daniel Kiper authored
Additionally, fix the terminfo spelling mistake in the GRUB development documentation. Signed-off-by:
Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com>
-
- Apr 12, 2021
-
-
Glenn Washburn authored
Signed-off-by:
Glenn Washburn <development@efficientek.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com>
-
Glenn Washburn authored
Signed-off-by:
Glenn Washburn <development@efficientek.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com>
-
- Mar 02, 2021
-
-
Petr Vorel authored
To give users hint why Argon2, the default in cryptsetup for LUKS2, does not work. Signed-off-by:
Petr Vorel <pvorel@suse.cz> Acked-by:
Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by:
Patrick Steinhardt <ps@pks.im> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com>
-
Alex Burmashev authored
The os-prober is enabled by default what may lead to potentially dangerous use cases and borderline opening attack vectors. This patch disables the os-prober, adds warning messages and updates GRUB_DISABLE_OS_PROBER configuration option documentation. This way we make it clear that the os-prober usage is not recommended. Simplistic nature of this change allows downstream vendors, who really want os-prober to be enabled out of the box in their relevant products, easily revert to it's old behavior. Reported-by:
NyankoSec <(<nyanko@10x.moe>,> https://twitter.com/NyankoSec ), working with SSD Secure Disclosure Signed-off-by:
Alex Burmashev <alexander.burmashev@oracle.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com>
-
Dimitri John Ledkov authored
Commit 32ddc42c (efi: Only register shim_lock verifier if shim_lock protocol is found and SB enabled) reintroduced CVE-2020-15705 which previously only existed in the out-of-tree linuxefi patches and was fixed as part of the BootHole patch series. Under Secure Boot enforce loading shim_lock verifier. Allow skipping shim_lock verifier if SecureBoot/MokSBState EFI variables indicate skipping validations, or if GRUB image is built with --disable-shim-lock. Fixes: 132ddc42 (efi: Only register shim_lock verifier if shim_lock protocol is found and SB enabled) Fixes: CVE-2020-15705 Fixes: CVE-2021-3418 Reported-by:
Dimitri John Ledkov <xnox@ubuntu.com> Signed-off-by:
Dimitri John Ledkov <xnox@ubuntu.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com>
-
Peter Jones authored
Add a --sbat option to the grub-mkimage tool which allows us to import an SBAT metadata formatted as a CSV file into a .sbat section of the EFI binary. Signed-off-by:
Peter Jones <pjones@redhat.com> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com>
-
Javier Martinez Canillas authored
The command is not present in the docs/grub.texi user documentation. Reported-by:
Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com>
-
Javier Martinez Canillas authored
There are some more commands that should be restricted when the GRUB is locked down. Following is the list of commands and reasons to restrict: * fakebios: creates BIOS-like structures for backward compatibility with existing OSes. This should not be allowed when locked down. * loadbios: reads a BIOS dump from storage and loads it. This action should not be allowed when locked down. * devicetree: loads a Device Tree blob and passes it to the OS. It replaces any Device Tree provided by the firmware. This also should not be allowed when locked down. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com>
-
Javier Martinez Canillas authored
The cutmem and badram commands can be used to remove EFI memory regions and potentially disable the UEFI Secure Boot. Prevent the commands to be registered if the GRUB is locked down. Fixes: CVE-2020-27779 Reported-by:
Teddy Reed <teddy.reed@gmail.com> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com>
-
Javier Martinez Canillas authored
The command is not allowed when lockdown is enforced. Otherwise an attacker can instruct the GRUB to load an SSDT table to overwrite the kernel lockdown configuration and later load and execute unsigned code. Fixes: CVE-2020-14372 Reported-by:
Máté Kukri <km@mkukri.xyz> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com>
-
Javier Martinez Canillas authored
Now the GRUB can check if it has been locked down and this can be used to prevent executing commands that can be utilized to circumvent the UEFI Secure Boot mechanisms. So, instead of hardcoding a list of modules that have to be disabled, prevent the usage of commands that can be dangerous. This not only allows the commands to be disabled on other platforms, but also properly separate the concerns. Since the shim_lock verifier logic should be only about preventing to run untrusted binaries and not about defining these kind of policies. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com>
-
Javier Martinez Canillas authored
It may be useful for scripts to determine whether the GRUB is locked down or not. Add the lockdown variable which is set to "y" when the GRUB is locked down. Suggested-by:
Dimitri John Ledkov <xnox@ubuntu.com> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com>
-
Javier Martinez Canillas authored
When the GRUB starts on a secure boot platform, some commands can be used to subvert the protections provided by the verification mechanism and could lead to booting untrusted system. To prevent that situation, allow GRUB to be locked down. That way the code may check if GRUB has been locked down and further restrict the commands that are registered or what subset of their functionality could be used. The lockdown support adds the following components: * The grub_lockdown() function which can be used to lockdown GRUB if, e.g., UEFI Secure Boot is enabled. * The grub_is_lockdown() function which can be used to check if the GRUB was locked down. * A verifier that flags OS kernels, the GRUB modules, Device Trees and ACPI tables as GRUB_VERIFY_FLAGS_DEFER_AUTH to defer verification to other verifiers. These files are only successfully verified if another registered verifier returns success. Otherwise, the whole verification process fails. For example, PE/COFF binaries verification can be done by the shim_lock verifier which validates the signatures using the shim_lock protocol. However, the verification is not deferred directly to the shim_lock verifier. The shim_lock verifier is hooked into the verification process instead. * A set of grub_{command,extcmd}_lockdown functions that can be used by code registering command handlers, to only register unsafe commands if the GRUB has not been locked down. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com>
-
Marco A Benatto authored
Move the shim_lock verifier from its own module into the core image. The Secure Boot lockdown mechanism has the intent to prevent the load of any unsigned code or binary when Secure Boot is enabled. The reason is that GRUB must be able to prevent executing untrusted code if UEFI Secure Boot is enabled, without depending on external modules. Signed-off-by:
Marco A Benatto <mbenatto@redhat.com> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com>
-
- Feb 27, 2021
-
-
Peter Jones authored
Add a --sbat option to the grub-mkimage tool which allows us to import an SBAT metadata formatted as a CSV file into a .sbat section of the EFI binary. Signed-off-by:
Peter Jones <pjones@redhat.com> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Patch-Name: 2021-02-security/107-util-mkimage-Add-an-option-to-import-SBAT-metadata-into-a-.sbat-section.patch
-
Javier Martinez Canillas authored
The command is not present in the docs/grub.texi user documentation. Reported-by:
Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Patch-Name: 2021-02-security/013-docs-Document-the-cutmem-command.patch
-
Javier Martinez Canillas authored
There are some more commands that should be restricted when the GRUB is locked down. Following is the list of commands and reasons to restrict: * fakebios: creates BIOS-like structures for backward compatibility with existing OSes. This should not be allowed when locked down. * loadbios: reads a BIOS dump from storage and loads it. This action should not be allowed when locked down. * devicetree: loads a Device Tree blob and passes it to the OS. It replaces any Device Tree provided by the firmware. This also should not be allowed when locked down. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Patch-Name: 2021-02-security/008-commands-Restrict-commands-that-can-load-BIOS-or-DT-blobs-when-locked-down.patch
-
Javier Martinez Canillas authored
The cutmem and badram commands can be used to remove EFI memory regions and potentially disable the UEFI Secure Boot. Prevent the commands to be registered if the GRUB is locked down. Fixes: CVE-2020-27779 Reported-by:
Teddy Reed <teddy.reed@gmail.com> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Patch-Name: 2021-02-security/007-mmap-Don-t-register-cutmem-and-badram-commands-when-lockdown-is-enforced.patch
-
Javier Martinez Canillas authored
The command is not allowed when lockdown is enforced. Otherwise an attacker can instruct the GRUB to load an SSDT table to overwrite the kernel lockdown configuration and later load and execute unsigned code. Fixes: CVE-2020-14372 Reported-by:
Máté Kukri <km@mkukri.xyz> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Patch-Name: 2021-02-security/006-acpi-Don-t-register-the-acpi-command-when-locked-down.patch
-
Javier Martinez Canillas authored
Now the GRUB can check if it has been locked down and this can be used to prevent executing commands that can be utilized to circumvent the UEFI Secure Boot mechanisms. So, instead of hardcoding a list of modules that have to be disabled, prevent the usage of commands that can be dangerous. This not only allows the commands to be disabled on other platforms, but also properly separate the concerns. Since the shim_lock verifier logic should be only about preventing to run untrusted binaries and not about defining these kind of policies. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Patch-Name: 2021-02-security/005-efi-Use-grub_is_lockdown-instead-of-hardcoding-a-disabled-modules-list.patch
-
Javier Martinez Canillas authored
It may be useful for scripts to determine whether the GRUB is locked down or not. Add the lockdown variable which is set to "y" when the GRUB is locked down. Suggested-by:
Dimitri John Ledkov <xnox@ubuntu.com> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Patch-Name: 2021-02-security/003-kern-lockdown-Set-a-variable-if-the-GRUB-is-locked-down.patch
-
Javier Martinez Canillas authored
When the GRUB starts on a secure boot platform, some commands can be used to subvert the protections provided by the verification mechanism and could lead to booting untrusted system. To prevent that situation, allow GRUB to be locked down. That way the code may check if GRUB has been locked down and further restrict the commands that are registered or what subset of their functionality could be used. The lockdown support adds the following components: * The grub_lockdown() function which can be used to lockdown GRUB if, e.g., UEFI Secure Boot is enabled. * The grub_is_lockdown() function which can be used to check if the GRUB was locked down. * A verifier that flags OS kernels, the GRUB modules, Device Trees and ACPI tables as GRUB_VERIFY_FLAGS_DEFER_AUTH to defer verification to other verifiers. These files are only successfully verified if another registered verifier returns success. Otherwise, the whole verification process fails. For example, PE/COFF binaries verification can be done by the shim_lock verifier which validates the signatures using the shim_lock protocol. However, the verification is not deferred directly to the shim_lock verifier. The shim_lock verifier is hooked into the verification process instead. * A set of grub_{command,extcmd}_lockdown functions that can be used by code registering command handlers, to only register unsafe commands if the GRUB has not been locked down. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Patch-Name: 2021-02-security/002-kern-Add-lockdown-support.patch
-
- Dec 18, 2020
-
-
Glenn Washburn authored
Document the artificially imposed 1 EiB disk size limit and size limitations with LUKS volumes. Fix a few punctuation issues. Signed-off-by:
Glenn Washburn <development@efficientek.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com>
-
- Dec 12, 2020
-
-
Vladimir Serbinenko authored
Signed-off-by:
Vladimir Serbinenko <phcoder@gmail.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com>
-
- Nov 20, 2020
-
-
Daniel Axtens authored
grub-install --pubkey is supported, so we can now document it. Signed-off-by:
Daniel Axtens <dja@axtens.net> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com>
-