From: Maxim Suhanov
This commit adds the grub_cryptodisk_erasesecrets() function to wipe
master keys from all cryptodisks. This function is EFI-only.
Since there is no easy way to "force unmount" a given encrypted disk,
this function renders all mounted cryptodisks unusable. An attempt to
read t
From: Maxim Suhanov
This command examines a given diskfilter device, e.g., an LVM disk,
and checks if underlying disks, physical volumes, are cryptodisks,
e.g., LUKS disks, this layout is called "LVM-on-LUKS".
The return value is 0 when all underlying disks (of a given device)
are cryptodisks (1
From: Michael Chang
The option can be used to suppress output if we only want to test the
return value of the command.
Also, mention this option in the documentation.
Signed-off-by: Michael Chang
Signed-off-by: Maxim Suhanov
Reviewed-by: Daniel Kiper
---
docs/grub.texi | 4 +++
From: Maxim Suhanov
When the --cryptodisk-only argument is given, also check the target
device using the "cryptocheck" command, if available.
This extends the checks to common layouts like LVM-on-LUKS, so the
--cryptodisk-only argument transparently handles such setups.
Signed-off-by: Maxim Suh
From: Maxim Suhanov
Switching to another EFI boot application while there are secrets in
RAM is dangerous, because not all firmware is wiping memory on free.
To reduce the attack surface, wipe the passphrase acquired when
unlocking an encrypted volume.
Signed-off-by: Maxim Suhanov
Reviewed-by:
From: Maxim Suhanov
Document the --cryptodisk-only argument. Also, document the
"cryptocheck" command invoked when that argument is processed.
Signed-off-by: Maxim Suhanov
Reviewed-by: Daniel Kiper
---
docs/grub.texi | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(
Hi all,
This patch set contains a bundle of fixes for various security flaws
discovered, as part of a pro-active hardening effort, in the GRUB2 code
recently. The most severe one, i.e. potentially exploitable, has CVE
assigned and is listed at the end of this email.
Details of exactly what needs
From: Maxim Suhanov
This allows users to restrict the "search" command's scope to
encrypted disks only.
Typically, this command is used to "rebase" $root and $prefix
before loading additional configuration files via "source" or
"configfile". Unfortunately, this leads to security problems,
like C
From: Maxim Suhanov
This further mitigates potential misuse of the CLI after the
root device has been successfully unlocked via TPM.
Fixes: CVE-2025-4382
Signed-off-by: Maxim Suhanov
Reviewed-by: Daniel Kiper
---
grub-core/kern/rescue_reader.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
From: Maxim Suhanov
This further mitigates potential misuse of the CLI after the
root device has been successfully unlocked via TPM.
Fixes: CVE-2025-4382
Signed-off-by: Maxim Suhanov
Reviewed-by: Daniel Kiper
---
grub-core/kern/rescue_reader.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
I believe haphazard ad-hoc approach is not a way to go. I see 2 valid
approaches:
* Have a central EFI to grub error converter that would print error code
and message
* Just print EFI error code in hex and tell that only experts are
interested in those details
Regards
Vladimir 'phcoder' Serbinenko
Le jeu. 8 mai 2025, 15:49, Yair Yarom a écrit :
> Initial testpci module and command used to query if PCI devices are
> present.
>
> ---
> docs/grub.texi | 8 ++
> grub-core/Makefile.core.def | 7 ++
> grub-core/commands/testpci.c | 167 +++
> 3
Initial testpci module and command used to query if PCI devices are
present.
---
docs/grub.texi | 8 ++
grub-core/Makefile.core.def | 7 ++
grub-core/commands/testpci.c | 167 +++
3 files changed, 182 insertions(+)
create mode 100644 grub-core/c
13 matches
Mail list logo