This reverts commits 47b2bee3ef
and 8d3c4544ff. It is not safe
to free allocated cards, dangling pointers main remain. Such
cleanup requires more changes in net core.
grub_memset should zero out padding after data end. It is not clear
why it is needed at all - ZFS block is at least 512 bytes and power
of two, so it is always multiple of 16 bytes. This grub_memset
apparently never did anything.
In the past birth was always zero for holes. This feature started
to make use of birth for holes as well, so change code to test for
valid DVA address instead.
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.
It can be called with NULL for third argument. grub_divmod32* for
now are called only from within wrappers, so skip check.
Reported-By: Michael Zimmermann <sigmaepsilon92@gmail.com>
Some x86 systems might be capable of running a 64-bit Linux kernel but
only use a 32-bit EFI (e.g. Intel Bay Trail systems). It's useful for
grub-install to be able to recognise such systems, to set the default
x86 platform correctly.
To allow grub-install to know the size of the firmware rather than
just the size of the kernel, there is now an extra EFI sysfs file to
describe the underlying firmware. Read that if possible, otherwise
fall back to the kernel type as before.
Signed-off-by: Steve McIntyre <steve@einval.com>
Use the new thumb_get_instruction_word/thumb_set_instruction_word
helpers throughout.
Style cleanup (missing spaces).
Move Thumb MOVW/MOVT handlers into Thumb relocation section of file.
This restrict ARP handling to MAC and IP addresses but in practice we need
only this case anyway and other cases are very rar if exist at all. It makes
code much simpler and less error-prone.
_BSD_SOURCE was added to allow the use of DT_DIR, but that was removed
in e768b77068. While adding
_DEFAULT_SOURCE as well works around problems with current glibc,
neither is in fact needed nowadays.
LVM miscalculates bitmap size with small extent, so start with 16K as
for other RAID types.
Until version 2.02.103 LVM counts metadata segments twice when checking
available space, reduce segment count by one to account for this bug.
Write activity with LVM/RAID can happen after filesystem is unmounted.
In my testing modification time of loop files was 15 - 20 seconds
after unmount. So use time as close to unmount as possible as
reference instead.
argp_help attempts to translate empty string, which results in printing
meta information about translation, like in
bor@opensuse:~/build/grub> grub2-mknetdir --help
Использование: grub2-mknetdir [ПАРАМЕТР…]
Project-Id-Version: grub 2.02-pre2
Report-Msgid-Bugs-To: bug-grub@gnu.org
...
Update gnulib/argp-help.c to the current version which fixes this
(commit b9bfe78424b871f5b92e5ee9e7d21ef951a6801d).
In file included from util/grub-mkimage.c:54:0:
./grub-core/gnulib/argp.h:627:49: error: '__sbistype' is static but
used in inline function '_option_is_short' which is not static
[-Werror] cc1: all warnings being treated as errors gmake[2]: ***
[util/grub_mkimage-grub-mkimage.o] Error 1
Update m4/extern-inline.m4 to current upstream gnulib version that
contains fix for this (commit b9bfe78424b871f5b92e5ee9e7d21ef951a6801d).
Reported-By: Beeblebrox <zaphod@berentweb.com>
