script: Do not allow a delimiter between function name and block start
Currently the following is valid syntax but should be a syntax error:
grub> function f; { echo HERE; }
grub> f
HERE
This fix is not backward compatible, but current syntax is not documented
either and has no functional value. So any scripts with this unintended
syntax are technically syntactically incorrect and should not be relying
on this behavior.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Fri, 28 Aug 2020 23:30:25 +0000 (18:30 -0500)]
tests: F2FS test should use MOUNTDEVICE like other tests
LODEVICES is not an array variable and should not be accessed as such.
This allows the f2fs test to pass as it was failing because a device
name had a space prepended to the path.
Signed-off-by: Glenn Washburn <development@efficientek.com> Acked-by: Jaegeuk Kim <jaegeuk@kernel.org> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The UUID header for LUKS2 uses a format with dashes, same as for
LUKS(1). But while we strip these dashes for the latter, we don't for
the former. This isn't wrong per se, but it's definitely inconsistent
for users as they need to use the dashed format for LUKS2 and the
non-dashed format for LUKS when e.g. calling "cryptomount -u $UUID".
Fix this inconsistency by stripping dashes off of the LUKS2 UUID.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Although the tpm_execute() series of functions are defined they are not
used anywhere. Several structures in the include/grub/efi/tpm.h header
file are not used too. There is even nonexistent grub_tpm_init()
declaration in this header. Delete all that unneeded stuff.
If somebody needs the functionality implemented in the dropped code then
he/she can re-add it later. Now it needlessly increases the GRUB
code/image size.
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
shim_lock: Enable module for all EFI architectures
Like the tpm the shim_lock module is only enabled for x86_64 target.
However, there's nothing specific to x86_64 in the implementation and
it can be enabled for all EFI architectures.
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Kiper [Mon, 25 May 2020 19:02:12 +0000 (21:02 +0200)]
docs: Fix devicetree command description
Specifically fix the subsection and drop bogus reference to the GNU/Linux.
Reported-by: Patrick Higgins <higgi1pt@gmail.com> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Martin Whitaker [Mon, 25 May 2020 19:02:10 +0000 (21:02 +0200)]
grub-install: Fix inverted test for NLS enabled when copying locales
Commit 3d8439da8 (grub-install: Locale depends on nls) attempted to avoid
copying locale files to the target directory when NLS was disabled.
However the test is inverted, and it does the opposite.
Signed-off-by: Martin Whitaker <fsf@martin-whitaker.me.uk> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
It is caused by the block number counter being a 16-bit field, which leads
to a maximum file size of ((1 << 16) - 1) * block size. Because GRUB sets
the block size to 1024 octets (by using the TFTP Blocksize Option from RFC
2348 [0]), the maximum file size that can be transferred is 67107840 bytes.
The TFTP PROTOCOL (REVISION 2) RFC 1350 [1] does not mention what a client
should do when a file size is bigger than the maximum, but most TFTP hosts
support the block number counter to be rolled over. That is, acking a data
packet with a block number of 0 is taken as if the 65356th block was acked.
It was working before because the block counter roll-over was happening due
an overflow. But that got fixed by the mentioned commit, which led to the
regression when attempting to fetch files larger than the maximum size.
To allow TFTP file transfers of unlimited size again, re-introduce a block
counter roll-over so the data packets are acked preventing the timeouts.
Fixes: 781b3e5efc3 (tftp: Do not use priority queue) Suggested-by: Peter Jones <pjones@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
cryptodisk: Fix incorrect calculation of start sector
Here dev is a grub_cryptodisk_t and dev->offset is offset in sectors of size
native to the cryptodisk device. The sector is correctly transformed into
native grub sector size, but then added to dev->offset which is not
transformed. It would be nice if the type system would help us with this.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
luks2: Improve error reporting when decrypting/verifying key
While we already set up error messages in both luks2_verify_key() and
luks2_decrypt_key(), we do not ever print them. This makes it really
hard to discover why a given key actually failed to decrypt a disk.
Improve this by including the error message in the user-visible output.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When configuring a LUKS disk, we copy over the UUID from the LUKS header
into the new grub_cryptodisk_t structure via grub_memcpy(). As size
we mistakenly use the size of the grub_cryptodisk_t UUID field, which
is guaranteed to be strictly bigger than the LUKS UUID field we're
copying. As a result, the copy always goes out-of-bounds and copies some
garbage from other surrounding fields. During runtime, this isn't
noticed due to the fact that we always NUL-terminate the UUID and thus
never hit the trailing garbage.
Fix the issue by using the size of the local stripped UUID field.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The C standard does not allow for typedef redefinitions, even if they
map to the same underlying type. In order to avoid including the
jsmn.h in json.h and thus exposing jsmn's internals, we have exactly
such a forward-declaring typedef in json.h. If enforcing the GNU99 C
standard, clang may generate a warning about this non-standard
construct.
Fix the issue by using a simple "struct jsmntok" forward declaration
instead of using a typedef.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Tested-by: Chuck Tuffli <chuck@freebsd.org> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Colin Watson [Sat, 25 Jul 2020 11:15:37 +0000 (12:15 +0100)]
linux: Fix integer overflows in initrd size handling
These could be triggered by a crafted filesystem with very large files.
Fixes: CVE-2020-15707 Signed-off-by: Colin Watson <cjwatson@debian.org> Reviewed-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
commit 92bfc33db984 ("efi: Free malloc regions on exit")
introduced memory freeing in grub_efi_fini(), which is
used not only by exit path but by halt/reboot one as well.
As result of memory freeing, code and data regions used by
modules, such as halt, reboot, acpi (used by halt) also got
freed. After return to module code, CPU executes, filled
by UEFI firmware (tested with edk2), 0xAFAFAFAF pattern as
a code. Which leads to #UD exception later.
Proposal here is to continue to free allocated memory for
exit boot services path but keep it for halt/reboot path
as it won't be much security concern here.
Introduced GRUB_LOADER_FLAG_EFI_KEEP_ALLOCATED_MEMORY
loader flag to be used by efi halt/reboot path.
Signed-off-by: Alexey Makhalov <amakhalov@vmware.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Kiper [Wed, 29 Jul 2020 11:38:31 +0000 (13:38 +0200)]
efi/chainloader: Propagate errors from copy_file_path()
Without any error propagated to the caller, make_file_path()
would then try to advance the invalid device path node with
GRUB_EFI_NEXT_DEVICE_PATH(), which would fail, returning a NULL
pointer that would subsequently be dereferenced. Hence, propagate
errors from copy_file_path().
Signed-off-by: Chris Coulson <chris.coulson@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Peter Jones [Sun, 19 Jul 2020 20:53:27 +0000 (16:53 -0400)]
efi: Fix some malformed device path arithmetic errors
Several places we take the length of a device path and subtract 4 from
it, without ever checking that it's >= 4. There are also cases where
this kind of malformation will result in unpredictable iteration,
including treating the length from one dp node as the type in the next
node. These are all errors, no matter where the data comes from.
This patch adds a checking macro, GRUB_EFI_DEVICE_PATH_VALID(), which
can be used in several places, and makes GRUB_EFI_NEXT_DEVICE_PATH()
return NULL and GRUB_EFI_END_ENTIRE_DEVICE_PATH() evaluate as true when
the length is too small. Additionally, it makes several places in the
code check for and return errors in these cases.
Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Peter Jones [Sun, 19 Jul 2020 20:08:08 +0000 (16:08 -0400)]
emu: Make grub_free(NULL) safe
The grub_free() implementation in grub-core/kern/mm.c safely handles
NULL pointers, and code at many places depends on this. We don't know
that the same is true on all host OSes, so we need to handle the same
behavior in grub-emu's implementation.
Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Peter Jones [Sun, 19 Jul 2020 19:48:20 +0000 (15:48 -0400)]
lvm: Fix two more potential data-dependent alloc overflows
It appears to be possible to make a (possibly invalid) lvm PV with
a metadata size field that overflows our type when adding it to the
address we've allocated. Even if it doesn't, it may be possible to do so
with the math using the outcome of that as an operand. Check them both.
Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Peter Jones [Sun, 19 Jul 2020 18:43:31 +0000 (14:43 -0400)]
hfsplus: Fix two more overflows
Both node->size and node->namelen come from the supplied filesystem,
which may be user-supplied. We can't trust them for the math unless we
know they don't overflow. Making sure they go through grub_add() or
grub_calloc() first will give us that.
Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
And this is valid. But following overflow protection will
unnecessarily move max_addr one byte down (to 0xffffefff):
if (max_addr > ~size)
max_addr = ~size;
~size + 1 will fix the situation. In addition, check size
for non zero to do not zero max_addr.
Signed-off-by: Alexey Makhalov <amakhalov@vmware.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Chris Coulson [Fri, 10 Jul 2020 13:41:45 +0000 (14:41 +0100)]
script: Avoid a use-after-free when redefining a function during execution
Defining a new function with the same name as a previously defined
function causes the grub_script and associated resources for the
previous function to be freed. If the previous function is currently
executing when a function with the same name is defined, this results
in use-after-frees when processing subsequent commands in the original
function.
Instead, reject a new function definition if it has the same name as
a previously defined function, and that function is currently being
executed. Although a behavioural change, this should be backwards
compatible with existing configurations because they can't be
dependent on the current behaviour without being broken.
Fixes: CVE-2020-15706 Signed-off-by: Chris Coulson <chris.coulson@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
relocator: Protect grub_relocator_alloc_chunk_align() max_addr against integer underflow
This commit introduces integer underflow mitigation in max_addr calculation
in grub_relocator_alloc_chunk_align() invocation.
It consists of 2 fixes:
1. Introduced grub_relocator_alloc_chunk_align_safe() wrapper function to perform
sanity check for min/max and size values, and to make safe invocation of
grub_relocator_alloc_chunk_align() with validated max_addr value. Replace all
invocations such as grub_relocator_alloc_chunk_align(..., min_addr, max_addr - size, size, ...)
by grub_relocator_alloc_chunk_align_safe(..., min_addr, max_addr, size, ...).
2. Introduced UP_TO_TOP32(s) macro for the cases where max_addr is 32-bit top
address (0xffffffff - size + 1) or similar.
Signed-off-by: Alexey Makhalov <amakhalov@vmware.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
relocator: Protect grub_relocator_alloc_chunk_addr() input args against integer underflow/overflow
Use arithmetic macros from safemath.h to accomplish it. In this commit,
I didn't want to be too paranoid to check every possible math equation
for overflow/underflow. Only obvious places (with non zero chance of
overflow/underflow) were refactored.
Signed-off-by: Alexey Makhalov <amakhalov@vmware.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
There is not need to reassemble the order of blocks. Per RFC 1350,
server must wait for the ACK, before sending next block. Data packets
can be served immediately without putting them to priority queue.
Logic to handle incoming packet is this:
- if packet block id equal to expected block id, then
process the packet,
- if packet block id is less than expected - this is retransmit
of old packet, then ACK it and drop the packet,
- if packet block id is more than expected - that shouldn't
happen, just drop the packet.
It makes the tftp receive path code simpler, smaller and faster.
As a benefit, this change fixes CID# 73624 and CID# 96690, caused
by following while loop:
while (cmp_block (grub_be_to_cpu16 (tftph->u.data.block), data->block + 1) == 0)
where tftph pointer is not moving from one iteration to another, causing
to serve same packet again. Luckily, double serving didn't happen due to
data->block++ during the first iteration.
This requires a very weird input from the serial interface but can cause
an overflow in input_buf (keys) overwriting the next variable (npending)
with the user choice:
(pahole output)
struct grub_terminfo_input_state {
int input_buf[6]; /* 0 24 */
int npending; /* 24 4 */ <- CORRUPT
...snip...
The magic string requires causing this is "ESC,O,],0,1,2,q" and we overflow
npending with "q" (aka increase npending to 161). The simplest fix is to
just to disallow overwrites input_buf, which exactly what this patch does.
Fixes: CID 292449 Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The two dimensional array p->posSlotEncoder[4][64] is being dereferenced
using the GetLenToPosState() macro which checks if len is less than 5,
and if so subtracts 2 from it. If len = 0, that is 0 - 2 = 4294967294.
Obviously we don't want to dereference that far out so we check if the
position found is greater or equal kNumLenToPosStates (4) and bail out.
N.B.: Upstream LZMA 18.05 and later has this function completely rewritten
without any history.
Fixes: CID 51526 Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Chris Coulson [Thu, 9 Jul 2020 18:04:43 +0000 (19:04 +0100)]
json: Avoid a double-free when parsing fails.
When grub_json_parse() succeeds, it returns the root object which
contains a pointer to the provided JSON string. Callers are
responsible for ensuring that this string outlives the root
object and for freeing its memory when it's no longer needed.
If grub_json_parse() fails to parse the provided JSON string,
it frees the string before returning an error. This results
in a double free in luks2_recover_key(), which also frees the
same string after grub_json_parse() returns an error.
This changes grub_json_parse() to never free the JSON string
passed to it, and updates the documentation for it to make it
clear that callers are responsible for ensuring that the string
outlives the root JSON object.
Fixes: CID 292465 Signed-off-by: Chris Coulson <chris.coulson@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Kiper [Tue, 7 Jul 2020 13:36:26 +0000 (15:36 +0200)]
font: Do not load more than one NAME section
The GRUB font file can have one NAME section only. Though if somebody
crafts a broken font file with many NAME sections and loads it then the
GRUB leaks memory. So, prevent against that by loading first NAME
section and failing in controlled way on following one.
Reported-by: Chris Coulson <chris.coulson@canonical.com> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com>
Peter Jones [Mon, 15 Jun 2020 16:28:27 +0000 (12:28 -0400)]
malloc: Use overflow checking primitives where we do complex allocations
This attempts to fix the places where we do the following where
arithmetic_expr may include unvalidated data:
X = grub_malloc(arithmetic_expr);
It accomplishes this by doing the arithmetic ahead of time using grub_add(),
grub_sub(), grub_mul() and testing for overflow before proceeding.
Among other issues, this fixes:
- allocation of integer overflow in grub_video_bitmap_create()
reported by Chris Coulson,
- allocation of integer overflow in grub_png_decode_image_header()
reported by Chris Coulson,
- allocation of integer overflow in grub_squash_read_symlink()
reported by Chris Coulson,
- allocation of integer overflow in grub_ext2_read_symlink()
reported by Chris Coulson,
- allocation of integer overflow in read_section_as_string()
reported by Chris Coulson.
Fixes: CVE-2020-14309, CVE-2020-14310, CVE-2020-14311 Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Peter Jones [Mon, 15 Jun 2020 16:26:01 +0000 (12:26 -0400)]
calloc: Use calloc() at most places
This modifies most of the places we do some form of:
X = malloc(Y * Z);
to use calloc(Y, Z) instead.
Among other issues, this fixes:
- allocation of integer overflow in grub_png_decode_image_header()
reported by Chris Coulson,
- allocation of integer overflow in luks_recover_key()
reported by Chris Coulson,
- allocation of integer overflow in grub_lvm_detect()
reported by Chris Coulson.
Fixes: CVE-2020-14308 Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Peter Jones [Mon, 15 Jun 2020 16:15:29 +0000 (12:15 -0400)]
calloc: Make sure we always have an overflow-checking calloc() available
This tries to make sure that everywhere in this source tree, we always have
an appropriate version of calloc() (i.e. grub_calloc(), xcalloc(), etc.)
available, and that they all safely check for overflow and return NULL when
it would occur.
Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Peter Jones [Mon, 15 Jun 2020 14:58:42 +0000 (10:58 -0400)]
safemath: Add some arithmetic primitives that check for overflow
This adds a new header, include/grub/safemath.h, that includes easy to
use wrappers for __builtin_{add,sub,mul}_overflow() declared like:
bool OP(a, b, res)
where OP is grub_add, grub_sub or grub_mul. OP() returns true in the
case where the operation would overflow and res is not modified.
Otherwise, false is returned and the operation is executed.
These arithmetic primitives require newer compiler versions. So, bump
these requirements in the INSTALL file too.
Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Peter Jones [Wed, 15 Apr 2020 19:45:02 +0000 (15:45 -0400)]
yylex: Make lexer fatal errors actually be fatal
When presented with a command that can't be tokenized to anything
smaller than YYLMAX characters, the parser calls YY_FATAL_ERROR(errmsg),
expecting that will stop further processing, as such:
The code flex generates expects that YY_FATAL_ERROR() will either return
for it or do some form of longjmp(), or handle the error in some way at
least, and so the strncpy() call isn't in an "else" clause, and thus if
YY_FATAL_ERROR() is *not* actually fatal, it does the call with the
questionable limit, and predictable results ensue.
Unfortunately, our implementation of YY_FATAL_ERROR() is:
#define YY_FATAL_ERROR(msg) \
do { \
grub_printf (_("fatal error: %s\n"), _(msg)); \
} while (0)
The same pattern exists in yyless(), and similar problems exist in users
of YY_INPUT(), several places in the main parsing loop,
yy_get_next_buffer(), yy_load_buffer_state(), yyensure_buffer_stack,
yy_scan_buffer(), etc.
All of these callers expect YY_FATAL_ERROR() to actually be fatal, and
the things they do if it returns after calling it are wildly unsafe.
Fixes: CVE-2020-10713 Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Marc Zyngier [Sun, 24 May 2020 11:32:48 +0000 (12:32 +0100)]
arm: Fix 32-bit ARM handling of the CTR register
When booting on an ARMv8 core that implements either CTR.IDC or CTR.DIC
(indicating that some of the cache maintenance operations can be
removed when dealing with I/D-cache coherency, GRUB dies with a
"Unsupported cache type 0x........" message.
This is pretty likely to happen when running in a virtual machine
hosted on an arm64 machine (I've triggered it on a system built around
a bunch of Cortex-A55 cores, which implements CTR.IDC).
It turns out that the way GRUB deals with the CTR register is a bit
harsh for anything from ARMv7 onwards. The layout of the register is
backward compatible, meaning that nothing that gets added is allowed to
break earlier behaviour. In this case, ignoring IDC is completely fine,
and only results in unnecessary cache maintenance.
We can thus avoid being paranoid, and align the 32bit behaviour with
its 64bit equivalent.
This patch has the added benefit that it gets rid of a (gnu-specific)
case range too.
Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Ian Jackson [Wed, 20 May 2020 12:14:19 +0000 (13:14 +0100)]
templates/20_linux_xen: Ignore xenpolicy and config files too
file_is_not_sym() currently only checks for xen-syms. Extend it to
disregard xenpolicy (XSM policy files) and files ending .config (which
are built by the Xen upstream build system in some configurations and
can therefore end up in /boot).
Rename the function accordingly, to file_is_not_xen_garbage().
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Nested functions are not supported in C, but are permitted as an extension
in the GNU C dialect. Commit cb2f15c5448 ("normal/main: Search for specific
config files for netboot") added a nested function which caused the build
to break when compiling with clang.
Break that out into a static helper function to make the code portable again.
Reported-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Kiper [Wed, 13 May 2020 12:02:48 +0000 (14:02 +0200)]
configure: Set gnu99 C language standard by default
Commit d5a32255d (misc: Make grub_strtol() "end" pointers have safer
const qualifiers) introduced "restrict" keyword into some functions
definitions. This keyword was introduced in C99 standard. However, some
compilers by default may use C89 or something different. This behavior
leads to the breakage during builds when c89 or gnu89 is in force. So,
let's set gnu99 C language standard for all compilers by default. This
way a bit random build issue will be fixed and the GRUB source will be
build consistently regardless of type and version of the compiler.
It was decided to use gnu99 C language standard because it fixes the
issue mentioned above and also provides some useful extensions which are
used here and there in the GRUB source. Potentially we can use gnu11
too. However, this may reduce pool of older compilers which can be used
to build the GRUB. So, let's live with gnu99 until we discover that we
strongly require a feature from newer C standard.
The user is still able to override C language standard using relevant
*_CFLAGS variables.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Tianjia Zhang [Wed, 13 May 2020 13:13:29 +0000 (21:13 +0800)]
tpm: Rename function grub_tpm_log_event() to grub_tpm_measure()
grub_tpm_log_event() and grub_tpm_measure() are two functions that
have the same effect. So, keep grub_tpm_log_event() and rename it
to grub_tpm_measure(). This way we get also a more clear semantics.
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
envblk: Fix buffer overrun when attempting to shrink a variable value
If an existing variable is set with a value whose length is smaller than
the current value, a memory corruption can happen due copying padding '#'
characters outside of the environment block buffer.
This is caused by a wrong calculation of the previous free space position
after moving backward the characters that followed the old variable value.
That position is calculated to fill the remaining of the buffer with the
padding '#' characters. But since isn't calculated correctly, it can lead
to copies outside of the buffer.
The issue can be reproduced by creating a variable with a large value and
then try to set a new value that is much smaller:
docs: Remove docs for non-existing uppermem command
Remove all documentation of and mentions of the uppermem
command from the docs/grub.texi file.
The uppermem command is not implemented in the GRUB source
at all and appears to never have been implemented despite
former plans to add an uppermem command.
To reduce user confusion, this even removes the paragraph
describing how GRUB's uppermem command was supposed to
complement the Linux kernel's mem= parameter.
Signed-off-by: Hans Ulrich Niedermann <hun@n-dimensional.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
docs: Remove docs for non-existing pxe_unload command
Remove the documentation of the pxe_unload command from the
docs/grub.texi file.
The pxe_unload command is not implemented in the grub source
at this time at all. It appears to have been removed in commit 671a78acb (cleanup pxe and efi network release).
Signed-off-by: Hans Ulrich Niedermann <hun@n-dimensional.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add a few patterns to .gitignore to cover files which are generated
by building grub ("make", "make check", "make dist") but which have
been forgotten to add to .gitignore in the past.
Signed-off-by: Hans Ulrich Niedermann <hun@n-dimensional.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Going through the list of gitignore patterns without a leading slash,
this adds a leading slash where it appears to have been forgotten.
Some gitignore patterns like ".deps/" or "Makefile" clearly should
match everywhere, so those definitively need no leading slash.
For some patterns like "ascii.bitmaps", it is unclear where in the
source tree they should match. Those patterns are kept as they are,
matching the patterns in the whole tree of subdirectories.
Signed-off-by: Hans Ulrich Niedermann <hun@n-dimensional.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
gitignore: Consistent leading slash is easier to read
As all gitignore patterns containing a left or middle slash match
only relative to the .gitignore file's directory, we write them
all in the same manner with a leading slash.
This makes the file significantly easier to read.
Signed-off-by: Hans Ulrich Niedermann <hun@n-dimensional.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
luks2: Propagate error when reading area key fails
When decrypting a given keyslot, all error cases except for one set up
an error and return the error code. The only exception is when we try to
read the area key: instead of setting up an error message, we directly
print it via grub_dprintf().
Convert the outlier to use grub_error() to allow more uniform handling
of errors.
Signed-off-by: Patrick Steinhardt <ps@kps.im> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
With the upstream change having landed that adds a name to the
previously anonymous "jsmntok" typedef, we can now add a forward
declaration for that struct in our code. As a result, we no longer have
to store the "tokens" member of "struct grub_json" as a void pointer but
can instead use the forward declaration, allowing us to get rid of casts
of that field.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Steve Langasek [Wed, 15 Apr 2020 10:32:17 +0000 (12:32 +0200)]
templates: Output a menu entry for firmware setup on UEFI FastBoot systems
The fwsetup command allows to reboot into the EFI firmware setup menu, add
a template to include a menu entry on EFI systems that makes use of that
command to reboot into the EFI firmware settings.
This is useful for users since the hotkey to enter into the EFI setup menu
may not be the same on all systems so users can use the menu entry without
needing to figure out what key needs to be pressed.
Also, if fastboot is enabled in the BIOS then often it is not possible to
enter the firmware setup menu. So the entry is again useful for this case.
Signed-off-by: Steve Langasek <steve.langasek@ubuntu.com> Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Hans de Goede [Wed, 15 Apr 2020 10:26:22 +0000 (12:26 +0200)]
kern/term: Accept ESC, F4 and holding SHIFT as user interrupt keys
On some devices the ESC key is the hotkey to enter the BIOS/EFI setup
screen, making it really hard to time pressing it right. Besides that
ESC is also pretty hard to discover for a user who does not know it
will unhide the menu.
This commit makes F4, which was chosen because is not used as a hotkey
to enter the BIOS setup by any vendor, also interrupt sleeps / stop the
menu countdown.
This solves the ESC gets into the BIOS setup and also somewhat solves
the discoverability issue, but leaves the timing issue unresolved.
This commit fixes the timing issue by also adding support for keeping
SHIFT pressed during boot to stop the menu countdown. This matches
what Ubuntu is doing, which should also help with discoverability.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Hans de Goede [Wed, 15 Apr 2020 10:26:21 +0000 (12:26 +0200)]
efi/console: Do not set text-mode until we actually need it
If we're running with a hidden menu we may never need text mode, so do not
change the video-mode to text until we actually need it.
This allows to boot a machine without unnecessary graphical transitions and
provide a seamless boot experience to users.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Hans de Goede [Wed, 15 Apr 2020 10:26:20 +0000 (12:26 +0200)]
efi/console: Implement getkeystatus() support
Implement getkeystatus() support in the EFI console driver.
This is needed because the logic to determine if a key was pressed to make
the menu countdown stop will be changed by a later patch to also take into
account the SHIFT key being held down.
For this reason the EFI console driver has to support getkeystatus() to
allow detecting that event.
Note that if a non-modifier key gets pressed and repeated calls to
getkeystatus() are made then it will return the modifier status at the
time of the non-modifier key, until that key-press gets consumed by a
getkey() call.
This is a side-effect of how the EFI simple-text-input protocol works
and cannot be avoided.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Hans de Goede [Wed, 15 Apr 2020 10:26:19 +0000 (12:26 +0200)]
efi/console: Add grub_console_read_key_stroke() helper function
This is a preparatory patch for adding getkeystatus() support to the
EFI console driver.
We can get modifier status through the simple_text_input read_key_stroke()
method, but if a non-modifier key is (also) pressed the read_key_stroke()
call will consume that key from the firmware's queue.
The new grub_console_read_key_stroke() helper buffers upto 1 key-stroke.
If it has a non-modifier key buffered, it will return that one, if its
buffer is empty, it will fills its buffer by getting a new key-stroke.
If called with consume=1 it will empty its buffer after copying the
key-data to the callers buffer, this is how getkey() will use it.
If called with consume=0 it will keep the last key-stroke buffered, this
is how getkeystatus() will call it. This means that if a non-modifier
key gets pressed, repeated getkeystatus() calls will return the modifiers
of that key-press until it is consumed by a getkey() call.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Hans de Goede [Wed, 15 Apr 2020 10:26:18 +0000 (12:26 +0200)]
kern/term: Make grub_getkeystatus() helper function available everywhere
Move grub_getkeystatushelper() function from grub-core/commands/keystatus.c
to grub-core/kern/term.c and export it so that it can be used outside of
the keystatus command code too.
There's no logic change in this patch. The function definition is moved so
it can be called from grub-core/kern/term.c in a subsequent patch. It will
be used to determine if a SHIFT key has was held down and use that also to
interrupt the countdown, without the need to press a key at the right time.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
efi/console: Move grub_console_set{colorstate,cursor} higher in the file
This is just a preparatory patch to move the functions higher in the file,
since these will be called by the grub_prepare_for_text_output() function
that will be introduced in a later patch.
The logic is unchanged by this patch. Functions definitions are just moved
to avoid a forward declaration in a later patch, keeping the code clean.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Tue, 7 Apr 2020 06:17:26 +0000 (16:17 +1000)]
powerpc/mkimage: Fix CHRP note descsz
Currently, an image generated with 'grub-mkimage -n' causes an error when
read with 'readelf -a':
Displaying notes found at file offset 0x000106f0 with length 0x0000002c:
Owner Data size Description
readelf: Warning: note with invalid namesz and/or descsz found at offset 0x0
readelf: Warning: type: 0x1275, namesize: 0x00000008, descsize: 0x0000002c, alignment: 4
This is because the descsz of the CHRP note is set to
sizeof (struct grub_ieee1275_note)
which is the size of the entire note, including name and elf header. The
desczs should contain only the contents, not the name and header sizes.
Set the descsz instead to 'sizeof (struct grub_ieee1275_note_desc)'
Michael Chang [Thu, 26 Mar 2020 06:35:35 +0000 (14:35 +0800)]
zfs: Fix gcc10 error -Werror=zero-length-bounds
We bumped into the build error while testing gcc-10 pre-release.
In file included from ../../include/grub/file.h:22,
from ../../grub-core/fs/zfs/zfs.c:34:
../../grub-core/fs/zfs/zfs.c: In function 'zap_leaf_lookup':
../../grub-core/fs/zfs/zfs.c:2263:44: error: array subscript '<unknown>' is outside the bounds of an interior zero-length array 'grub_uint16_t[0]' {aka 'short unsigned int[0]'} [-Werror=zero-length-bounds]
2263 | for (chunk = grub_zfs_to_cpu16 (l->l_hash[LEAF_HASH (blksft, h, l)], endian);
../../include/grub/types.h:241:48: note: in definition of macro 'grub_le_to_cpu16'
241 | # define grub_le_to_cpu16(x) ((grub_uint16_t) (x))
| ^
../../grub-core/fs/zfs/zfs.c:2263:16: note: in expansion of macro 'grub_zfs_to_cpu16'
2263 | for (chunk = grub_zfs_to_cpu16 (l->l_hash[LEAF_HASH (blksft, h, l)], endian);
| ^~~~~~~~~~~~~~~~~
In file included from ../../grub-core/fs/zfs/zfs.c:48:
../../include/grub/zfs/zap_leaf.h:72:16: note: while referencing 'l_hash'
72 | grub_uint16_t l_hash[0];
| ^~~~~~
Here I'd like to quote from the gcc document [1] which seems best to
explain what is going on here.
"Although the size of a zero-length array is zero, an array member of
this kind may increase the size of the enclosing type as a result of
tail padding. The offset of a zero-length array member from the
beginning of the enclosing structure is the same as the offset of an
array with one or more elements of the same type. The alignment of a
zero-length array is the same as the alignment of its elements.
Declaring zero-length arrays in other contexts, including as interior
members of structure objects or as non-member objects, is discouraged.
Accessing elements of zero-length arrays declared in such contexts is
undefined and may be diagnosed."
The l_hash[0] is apparnetly an interior member to the enclosed structure
while l_entries[0] is the trailing member. And the offending code tries
to access members in l_hash[0] array that triggers the diagnose.
Given that the l_entries[0] is used to get proper alignment to access
leaf chunks, we can accomplish the same thing through the ALIGN_UP macro
thus eliminating l_entries[0] from the structure. In this way we can
pacify the warning as l_hash[0] now becomes the last member to the
enclosed structure.
We bumped into the build error while testing gcc-10 pre-release.
../../grub-core/disk/mdraid1x_linux.c: In function 'grub_mdraid_detect':
../../grub-core/disk/mdraid1x_linux.c:181:15: error: array subscript <unknown> is outside array bounds of 'grub_uint16_t[0]' {aka 'short unsigned int[0]'} [-Werror=array-bounds]
181 | (char *) &sb.dev_roles[grub_le_to_cpu32 (sb.dev_number)]
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../grub-core/disk/mdraid1x_linux.c:98:17: note: while referencing 'dev_roles'
98 | grub_uint16_t dev_roles[0]; /* Role in array, or 0xffff for a spare, or 0xfffe for faulty. */
| ^~~~~~~~~
../../grub-core/disk/mdraid1x_linux.c:127:33: note: defined here 'sb'
127 | struct grub_raid_super_1x sb;
| ^~
cc1: all warnings being treated as errors
Apparently gcc issues the warning when trying to access sb.dev_roles
array's member, since it is a zero length array as the last element of
struct grub_raid_super_1x that is allocated sparsely without extra
chunks for the trailing bits, so the warning looks legitimate in this
regard.
As the whole thing here is doing offset computation, it is undue to use
syntax that would imply array member access then take address from it
later. Instead we could accomplish the same thing through basic array
pointer arithmetic to pacify the warning.
Signed-off-by: Michael Chang <mchang@suse.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Simon Hardy [Tue, 24 Mar 2020 13:29:12 +0000 (13:29 +0000)]
build: Fix GRUB i386-pc build with Ubuntu gcc
With recent versions of gcc on Ubuntu a very large lzma_decompress.img file is
output. (e.g. 134479600 bytes instead of 2864.) This causes grub-mkimage to
fail with: "error: Decompressor is too big."
This seems to be caused by a section .note.gnu.property that is placed at an
offset such that objcopy needs to pad the img file with zeros.
This issue is present on:
Ubuntu 19.10 with gcc (Ubuntu 8.3.0-26ubuntu1~19.10) 8.3.0
Ubuntu 19.10 with gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
This issue is not present on:
Ubuntu 19.10 with gcc (Ubuntu 7.5.0-3ubuntu1~19.10) 7.5.0
RHEL 8.0 with gcc 8.3.1 20190507 (Red Hat 8.3.1-4)
The issue can be fixed by removing the section using objcopy as shown in
this patch.
Signed-off-by: Simon Hardy <simon.hardy@itdev.co.uk> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Michael Chang [Thu, 19 Mar 2020 05:56:13 +0000 (13:56 +0800)]
lvm: Add LVM cache logical volume handling
The LVM cache logical volume is the logical volume consisting of the original
and the cache pool logical volume. The original is usually on a larger and
slower storage device while the cache pool is on a smaller and faster one. The
performance of the original volume can be improved by storing the frequently
used data on the cache pool to utilize the greater performance of faster
device.
The default cache mode "writethrough" ensures that any data written will be
stored both in the cache and on the origin LV, therefore grub can be straight
to read the original lv as no data loss is guarenteed.
The second cache mode is "writeback", which delays writing from the cache pool
back to the origin LV to have increased performance. The drawback is potential
data loss if losing the associated cache device.
During the boot time grub reads the LVM offline i.e. LVM volumes are not
activated and mounted, hence it should be fine to read directly from original
lv since all cached data should have been flushed back in the process of taking
it offline.
It is also not much helpful to the situation by adding fsync calls to the
install code. The fsync did not force to write back dirty cache to the original
device and rather it would update associated cache metadata to complete the
write transaction with the cache device. IOW the writes to cached blocks still
go only to the cache device.
To write back dirty cache, as LVM cache did not support dirty cache flush per
block range, there'no way to do it for file. On the other hand the "cleaner"
policy is implemented and can be used to write back "all" dirty blocks in a
cache, which effectively drain all dirty cache gradually to attain and last in
the "clean" state, which can be useful for shrinking or decommissioning a
cache. The result and effect is not what we are looking for here.
In conclusion, as it seems no way to enforce file writes to the original
device, grub may suffer from power failure as it cannot assemble the cache
device and read the dirty data from it. However since the case is only
applicable to writeback mode which is sensitive to data lost in nature, I'd
still like to propose my (relatively simple) patch and treat reading dirty
cache as improvement.
Signed-off-by: Michael Chang <mchang@suse.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
gnulib: Fix build of base64 when compiling with memory debugging
When building GRUB with memory management debugging enabled, then the
build fails because of `grub_debug_malloc()` and `grub_debug_free()`
being undefined in the luks2 module. The cause is that we patch
"base64.h" to unconditionaly include "config-util.h", which shouldn't be
included for modules at all. As a result, `MM_DEBUG` is defined when
building the module, causing it to use the debug memory allocation
functions. As these are not built into modules, we end up with a linker
error.
Fix the issue by removing the <config-util.h> include altogether. The
sole reason it was included was for the `_GL_ATTRIBUTE_CONST` macro,
which we can simply define as empty in case it's not set.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
build: Fix option to explicitly disable memory debugging
The memory management system supports a debug mode that can be enabled
at build time by passing "--enable-mm-debug" to the configure script.
Passing the option will cause us define MM_DEBUG as expected, but in
fact the reverse option "--disable-mm-debug" will do the exact same
thing and also set up the define. This currently causes the build of
"lib/gnulib/base64.c" to fail as it tries to use `grub_debug_malloc()`
and `grub_debug_free()` even though both symbols aren't defined.
Seemingly, `AC_ARG_ENABLE()` will always execute the third argument if
either the positive or negative option was passed. Let's thus fix the
issue by moving the call to`AC_DEFINE()` into an explicit `if test
$xenable_mm_debug` block, similar to how other defines work.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Mike Gilbert [Thu, 5 Mar 2020 21:52:18 +0000 (16:52 -0500)]
datetime: Enable the datetime module for the emu platform
Fixes a build failure:
grub-core/commands/date.c:49: undefined reference to `grub_get_weekday_name'
grub-core/commands/ls.c:155: undefined reference to `grub_unixtime2datetime'
Bug: https://bugs.gentoo.org/711512
Signed-off-by: Mike Gilbert <floppym@gentoo.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
While GRUB has no platform support for SuperH (sh4) yet, this change
adds the target-specific handling of soft-floats such that the GRUB
utilities can be built on this target.
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Peter Jones [Wed, 4 Mar 2020 11:58:51 +0000 (12:58 +0100)]
efi: Fix the type of grub_efi_status_t
Currently, in some builds with some checkers, we see:
1. grub-core/disk/efi/efidisk.c:601: error[shiftTooManyBitsSigned]: Shifting signed 64-bit value by 63 bits is undefined behaviour
This is because grub_efi_status_t is defined as grub_efi_intn_t, which is
signed, and shifting into the sign bit is not defined behavior. UEFI fixed
this in the spec in 2.3:
2.3 | Change the defined type of EFI_STATUS from INTN to UINTN | May 7, 2009
And the current EDK2 code has:
MdePkg/Include/Base.h-//
MdePkg/Include/Base.h-// Status codes common to all execution phases
MdePkg/Include/Base.h-//
MdePkg/Include/Base.h:typedef UINTN RETURN_STATUS;
MdePkg/Include/Base.h-
MdePkg/Include/Base.h-/**
MdePkg/Include/Base.h- Produces a RETURN_STATUS code with the highest bit set.
MdePkg/Include/Base.h-
MdePkg/Include/Base.h- @param StatusCode The status code value to convert into a warning code.
MdePkg/Include/Base.h- StatusCode must be in the range 0x00000000..0x7FFFFFFF.
MdePkg/Include/Base.h-
MdePkg/Include/Base.h- @return The value specified by StatusCode with the highest bit set.
MdePkg/Include/Base.h-
MdePkg/Include/Base.h-**/
MdePkg/Include/Base.h-#define ENCODE_ERROR(StatusCode) ((RETURN_STATUS)(MAX_BIT | (StatusCode)))
MdePkg/Include/Base.h-
MdePkg/Include/Base.h-/**
MdePkg/Include/Base.h- Produces a RETURN_STATUS code with the highest bit clear.
MdePkg/Include/Base.h-
MdePkg/Include/Base.h- @param StatusCode The status code value to convert into a warning code.
MdePkg/Include/Base.h- StatusCode must be in the range 0x00000000..0x7FFFFFFF.
MdePkg/Include/Base.h-
MdePkg/Include/Base.h- @return The value specified by StatusCode with the highest bit clear.
MdePkg/Include/Base.h-
MdePkg/Include/Base.h-**/
MdePkg/Include/Base.h-#define ENCODE_WARNING(StatusCode) ((RETURN_STATUS)(StatusCode))
MdePkg/Include/Base.h-
MdePkg/Include/Base.h-/**
MdePkg/Include/Base.h- Returns TRUE if a specified RETURN_STATUS code is an error code.
MdePkg/Include/Base.h-
MdePkg/Include/Base.h- This function returns TRUE if StatusCode has the high bit set. Otherwise, FALSE is returned.
MdePkg/Include/Base.h-
MdePkg/Include/Base.h- @param StatusCode The status code value to evaluate.
MdePkg/Include/Base.h-
MdePkg/Include/Base.h- @retval TRUE The high bit of StatusCode is set.
MdePkg/Include/Base.h- @retval FALSE The high bit of StatusCode is clear.
MdePkg/Include/Base.h-
MdePkg/Include/Base.h-**/
MdePkg/Include/Base.h-#define RETURN_ERROR(StatusCode) (((INTN)(RETURN_STATUS)(StatusCode)) < 0)
...
Uefi/UefiBaseType.h:typedef RETURN_STATUS EFI_STATUS;
This patch makes grub's implementation match the Edk2 declaration with regards
to the signedness of the type.
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>
projects / grub2.git / log