If grub is signed with a key that's in the trusted EFI keyring, an attacker
can point a boot entry at grub rather than at shim and grub will fail to
locate the shim verification protocol. This would then allow booting an
arbitrary kernel image. Fail validation if Secure Boot is enabled and we
can't find the shim protocol in order to prevent this.
Hi,
Fedora's patch to forbid insmod in UEFI Secure Boot environments is fine
as far as it goes. However, the insmod command is not the only way that
modules can be loaded. In particular, the 'normal' command, which
implements the usual GRUB menu and the fully-featured command prompt,
will implicitly load commands not currently loaded into memory. This
permits trivial Secure Boot violations by writing commands implementing
whatever you want to do and pointing $prefix at the malicious code.
I'm currently test-building this patch (replacing your current
grub-2.00-no-insmod-on-sb.patch), but this should be more correct. It
moves the check into grub_dl_load_file.
Basic usage would look something like this:
gptprio.next -d usr_dev -u usr_uuid
linuxefi ($usr_dev)/boot/vmlinuz mount.usr=PARTUUID=$usr_uuid
After booting the system should set the 'successful' bit on the
partition that was used.
The EFI version of grub_machine_get_bootlocation crops the boot image
name back to the last / in order to get a directory path. However, it
does not check that *name is actually set before calling grub_strrchr
to do this, and neither does grub_strrchr before dereferencing a NULL
pointer.
Parent function, grub_set_prefix_and_root, does check the pointer
before using.
The structure size used in grub_netbuff_pull to get the pointer to
option header is apparently wrong, which leads to subsequent range check
failed and therefore not responding to any neighbor solicit message in my
testing.
The first hint of something practical, a command that can restore any of
the GPT structures from the alternate location. New test case must run
under QEMU because the loopback device used by the other unit tests does
not support writing.
The header location fields refer to 'this header' and 'alternate header'
respectively, not 'primary header' and 'backup header'. The previous
field names are backwards for the backup header.
This module is a new implementation for reading GUID Partition Tables
which is much stricter than the existing part_gpt module and exports GPT
data directly instead of the generic grub_partition structure. It will
be the basis for modules that need to read/write/update GPT data.
The current code does nothing more than read and verify the table.
struct ... foo = { 0, } is valid initializer, but older GCC emits
warning which is fatal error due to -Werror=missing-field-initializer.
So simply use full initializer to avoid these errors. This was fixed
probably in GCC 4.7.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36750
The AML parser implements only a small subset of possible AML
opcodes. On the Fujitsu Lifebook E744 this and another bug in
the parser (incorrect handling of TermArg data types) would lead
to the laptop not turning off (_S5 not found).
* grub-core/commands/acpihalt.c: Support OpAlias in the AML parser;
in skip_ext_op(), handle some Type2Opcodes more correctly (TermArgs
aren't always simply strings!); Add function to skip TermArgs
* include/grub/acpi.h: Add new opcodes
Currently, if "linux" fails, the "goto fail;" in grub_cmd_initrd sends us
into grub_initrd_close() without grub_initrd_init() being called, and thus
it never clears initrd_ctx->components. grub_initrd_close() then frees that
address, which is stale data from the stack. If the stack happens to have a
stale *address* there that matches a recent allocation, then you'll get a
double free later.
So initialize the memory up front.
Signed-off-by: Peter Jones <pjones@redhat.com>
We encountered a weird random kernel initrd unpacking error on btrfs
and finally found it was caused by incorrect address reference in range
check for type GRUB_BTRFS_EXTENT_REGULAR and the entire result is
unpredictable.
This is a quick fix to make the address reference to the
grub_btrfs_extent_data structure correctly, not the pointer variable
to it.
Any suggestions to this patch is welcome.
* configure.ac: Remove -m64 from checks for -mcmodel=large and
-mno-red-zone. These are always either unnecessary (x86_64-emu) or
already in TARGET_CFLAGS at this point, and they produce incorrect
results when building for x32.
* grub-core/kern/x86_64/dl.c (grub_arch_dl_relocate_symbols): Cast
pointers to Elf64_Xword via grub_addr_t, in order to work on x32.
* include/grub/x86_64/types.h (GRUB_TARGET_SIZEOF_VOID_P,
GRUB_TARGET_SIZEOF_LONG): Define to 4 on x32.
Commit 588744d0dc caused grub-mkconfig
no longer to be forgiving of trailing spaces on grub-probe output
lines, which among other things means that util/grub.d/10_linux.in
no longer detects LVM. To fix this, make grub-probe's output
delimiting more consistent. As a bonus, this improves the coverage
of the -0 option.
Fixes Debian bug #735935.
* grub-core/disk/cryptodisk.c
(grub_util_cryptodisk_get_abstraction): Add a user-data argument.
* grub-core/disk/diskfilter.c (grub_diskfilter_get_partmap):
Likewise.
* include/grub/cryptodisk.h (grub_util_cryptodisk_get_abstraction):
Update prototype.
* include/grub/diskfilter.h (grub_diskfilter_get_partmap): Likewise.
* util/grub-install.c (push_partmap_module, push_cryptodisk_module,
probe_mods): Adjust for extra user-data arguments.
* util/grub-probe.c (do_print, probe_partmap, probe_cryptodisk_uuid,
probe_abstraction): Use configured delimiter. Update callers.
is_qemu is not being set lead to disabling of feature like
GRUB_IEEE1275_FLAG_HAS_CURSORONOFF. This resulted in cursor not being
displayed during the grub-menu edit.
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
