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>
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>
grub_xnu_devprop_add_property() should not free utf8 and utf16 as it get
allocated and freed in the caller.
Minor improvement: do prop fields initialization after memory allocations.
Fixes: CID 292442, CID 292457, CID 292460, CID 292466
Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
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>
Currently the string functions grub_strtol(), grub_strtoul(), and
grub_strtoull() don't declare the "end" pointer in such a way as to
require the pointer itself or the character array to be immutable to the
implementation, nor does the C standard do so in its similar functions,
though it does require us not to change any of it.
The typical declarations of these functions follow this pattern:
long
strtol(const char * restrict nptr, char ** restrict endptr, int base);
Much of the reason for this is historic, and a discussion of that
follows below, after the explanation of this change. (GRUB currently
does not include the "restrict" qualifiers, and we name the arguments a
bit differently.)
The implementation is semantically required to treat the character array
as immutable, but such accidental modifications aren't stopped by the
compiler, and the semantics for both the callers and the implementation
of these functions are sometimes also helped by adding that requirement.
This patch changes these declarations to follow this pattern instead:
long
strtol(const char * restrict nptr,
const char ** const restrict endptr,
int base);
This means that if any modification to these functions accidentally
introduces either an errant modification to the underlying character
array, or an accidental assignment to endptr rather than *endptr, the
compiler should generate an error. (The two uses of "restrict" in this
case basically mean strtol() isn't allowed to modify the character array
by going through *endptr, and endptr isn't allowed to point inside the
array.)
It also means the typical use case changes to:
char *s = ...;
const char *end;
long l;
l = strtol(s, &end, 10);
Or even:
const char *p = str;
while (p && *p) {
long l = strtol(p, &p, 10);
...
}
This fixes 26 places where we discard our attempts at treating the data
safely by doing:
const char *p = str;
long l;
l = strtol(p, (char **)&ptr, 10);
It also adds 5 places where we do:
char *p = str;
while (p && *p) {
long l = strtol(p, (const char ** const)&p, 10);
...
/* more calls that need p not to be pointer-to-const */
}
While moderately distasteful, this is a better problem to have.
With one minor exception, I have tested that all of this compiles
without relevant warnings or errors, and that /much/ of it behaves
correctly, with gcc 9 using 'gcc -W -Wall -Wextra'. The one exception
is the changes in grub-core/osdep/aros/hostdisk.c , which I have no idea
how to build.
Because the C standard defined type-qualifiers in a way that can be
confusing, in the past there's been a slow but fairly regular stream of
churn within our patches, which add and remove the const qualifier in many
of the users of these functions. This change should help avoid that in
the future, and in order to help ensure this, I've added an explanation
in misc.h so that when someone does get a compiler warning about a type
error, they have the fix at hand.
The reason we don't have "const" in these calls in the standard is
purely anachronistic: C78 (de facto) did not have type qualifiers in the
syntax, and the "const" type qualifier was added for C89 (I think; it
may have been later). strtol() appears to date from 4.3BSD in 1986,
which means it could not be added to those functions in the standard
without breaking compatibility, which is usually avoided.
The syntax chosen for type qualifiers is what has led to the churn
regarding usage of const, and is especially confusing on string
functions due to the lack of a string type. Quoting from C99, the
syntax is:
declarator:
pointer[opt] direct-declarator
direct-declarator:
identifier
( declarator )
direct-declarator [ type-qualifier-list[opt] assignment-expression[opt] ]
...
direct-declarator [ type-qualifier-list[opt] * ]
...
pointer:
* type-qualifier-list[opt]
* type-qualifier-list[opt] pointer
type-qualifier-list:
type-qualifier
type-qualifier-list type-qualifier
...
type-qualifier:
const
restrict
volatile
So the examples go like:
const char foo; // immutable object
const char *foo; // mutable pointer to object
char * const foo; // immutable pointer to mutable object
const char * const foo; // immutable pointer to immutable object
const char const * const foo; // XXX extra const keyword in the middle
const char * const * const foo; // immutable pointer to immutable
// pointer to immutable object
const char ** const foo; // immutable pointer to mutable pointer
// to immutable object
Making const left-associative for * and right-associative for everything
else may not have been the best choice ever, but here we are, and the
inevitable result is people using trying to use const (as they should!),
putting it at the wrong place, fighting with the compiler for a bit, and
then either removing it or typecasting something in a bad way. I won't
go into describing restrict, but its syntax has exactly the same issue
as with const.
Anyway, the last example above actually represents the *behavior* that's
required of strtol()-like functions, so that's our choice for the "end"
pointer.
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Recent work around x86 Linux kernel loader revealed an underflow in the
setup_header length calculation and another related issue. Both lead to
the memory overwrite and later machine crash.
Currently when the GRUB copies the setup_header into the linux_params
(struct boot_params, traditionally known as "zero page") it assumes the
setup_header size as sizeof(linux_i386_kernel_header/lh). This is
incorrect. It should use the value calculated accordingly to the Linux
kernel boot protocol. Otherwise in case of pretty old kernel, to be
exact Linux kernel boot protocol, the GRUB may write more into
linux_params than it was expected to. Fortunately this is not very big
issue. Though it has to be fixed. However, there is also an underflow
which is grave. It happens when
sizeof(linux_i386_kernel_header/lh) > "real size of the setup_header".
Then len value wraps around and grub_file_read() reads whole kernel into
the linux_params overwriting memory past it. This leads to the GRUB
memory allocator breakage and finally to its crash during boot.
The patch fixes both issues. Additionally, it moves the code not related to
grub_memset(linux_params)/grub_memcpy(linux_params)/grub_file_read(linux_params)
section outside of it to not confuse the reader.
Fixes: e683cfb0cf (loader/i386/linux: Calculate the setup_header length)
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Previously the setup_header length was just assumed to be the size of the
linux_kernel_params struct. The linux x86 32-bit boot protocol says that the
end of the linux_i386_kernel_header is at 0x202 + the byte value at 0x201 in
the linux_i386_kernel_header. So, calculate the size of the header using the
end of the linux_i386_kernel_header, rather than assume it is the size of the
linux_kernel_params struct.
Additionally, add some required members to the linux_kernel_params
struct and align the content of linux_i386_kernel_header struct with
it. New members naming was taken directly from Linux kernel source.
linux_kernel_params and linux_i386_kernel_header structs require more
cleanup. However, this is not urgent, so, let's do this after release.
Just in case...
Signed-off-by: Andrew Jeddeloh <andrew.jeddeloh@coreos.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@google.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Mirror behaviour of ELF loader in libxc: first look for Xen notes in
PT_NOTE segment, then in SHT_NOTE section and only then fallback to
a section with __xen_guest name. This fixes loading PV kernels that
Xen note have outside of PT_NOTE. While this may be result of a buggy
linker script, loading such kernel directly works fine, so make it work
with GRUB too. Specifically, this applies to binaries built from Unikraft.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add the hooks to current code needed for Xen PVH. They will be filled
with code later when the related functionality is being added.
loader/i386/linux.c needs to include machine/kernel.h now as it needs
to get GRUB_KERNEL_USE_RSDP_ADDR from there. This in turn requires to
add an empty kernel.h header for some i386 platforms (efi, coreboot,
ieee1275, xen) and for x86_64 efi.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Xen PVH guests will have the RSDP at an arbitrary address. Support that
by passing the RSDP address via the boot parameters to Linux.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Xen fallout cleanup after commit ca0a4f689 (verifiers: File type for
fine-grained signature-verification controlling).
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Let's provide file type info to the I/O layer. This way verifiers
framework and its users will be able to differentiate files and verify
only required ones.
This is preparatory patch.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
1. move relocator related code more close to each other
2. use variable "len" since it has correct assignment, and keep coding
style with upper code
Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Delete local copy of function to determine required buffer size for the
UEFI memory map, use helper in kern/efi/mm.c.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The EFI Graphics Output Protocol can return a 64-bit
linear frame buffer address in some firmware/BIOS
implementations. We currently only store the lower
32-bits in the lfb_base. This will eventually be
passed to Linux kernel and the efifb driver will
incorrectly interpret the framebuffer address as
32-bit address.
The Linux kernel has already added support to handle
64-bit linear framebuffer address in the efifb driver
since quite some time now.
This patch adds the support for 64-bit linear frame
buffer address in GRUB to address the above mentioned
scenario.
Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
These fields must reflect the ROM-BIOS's geometry for CHS-based
loaders to correctly load their next stage. Most loaders do not
query the ROM-BIOS (Int13.08), relying on the BPB fields to hold
the correct values already.
Tested with lDebug booted in qemu via grub2's
FreeDOS direct loading support, refer to
https://bitbucket.org/ecm/ldosboot + https://bitbucket.org/ecm/ldebug
(For this test, lDebug's iniload.asm must be assembled with
-D_QUERY_GEOMETRY=0 to leave the BPB values provided by grub.)
Signed-off-by: C. Masloch <pushbx@38.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Rename GRUB_LINUX_MAGIC_SIGNATURE GRUB_LINUX_I386_MAGIC_SIGNATURE,
to be usable in code that supports more than one image type.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The definition of bpb's num_total_sectors_16 and num_total_sectors_32
is that either the 16-bit field is non-zero and is used (in which case
eg mkfs.fat sets the 32-bit field to zero), or it is zero and the
32-bit field is used. Therefore, a BPB is invalid only if *both*
fields are zero; having one field as zero and the other as non-zero is
the case to be expected. (Indeed, according to Microsoft's specification
one of the fields *must* be zero, and the other non-zero.)
This affects all users of grub_chainloader_patch_bpb which are in
chainloader.c, freedos.c, and ntldr.c
Some descriptions of the semantics of these two fields:
https://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html
The old 2-byte fields "total number of sectors" and "number of
sectors per FAT" are now zero; this information is now found in
the new 4-byte fields.
(Here given in the FAT32 EBPB section but the total sectors 16/32 bit
fields semantic is true of FAT12 and FAT16 too.)
https://wiki.osdev.org/FAT#BPB_.28BIOS_Parameter_Block.29
19 | 2 | The total sectors in the logical volume. If this value is 0,
it means there are more than 65535 sectors in the volume, and the actual
count is stored in "Large Sectors (bytes 32-35).
32 | 4 | Large amount of sector on media. This field is set if there
are more than 65535 sectors in the volume.
(Doesn't specify what the "large" field is set to when unused, but as
mentioned mkfs.fat sets it to zero then.)
https://technet.microsoft.com/en-us/library/cc976796.aspx
0x13 | WORD | 0x0000 |
Small Sectors . The number of sectors on the volume represented in 16
bits (< 65,536). For volumes larger than 65,536 sectors, this field
has a value of zero and the Large Sectors field is used instead.
0x20 | DWORD | 0x01F03E00 |
Large Sectors . If the value of the Small Sectors field is zero, this
field contains the total number of sectors in the FAT16 volume. If the
value of the Small Sectors field is not zero, the value of this field
is zero.
https://staff.washington.edu/dittrich/misc/fatgen103.pdf page 10
BPB_TotSec16 | 19 | 2 |
This field is the old 16-bit total count of sectors on the volume.
This count includes the count of all sectors in all four regions of the
volume. This field can be 0; if it is 0, then BPB_TotSec32 must be
non-zero. For FAT32 volumes, this field must be 0. For FAT12 and
FAT16 volumes, this field contains the sector count, and
BPB_TotSec32 is 0 if the total sector count “fits” (is less than
0x10000).
BPB_TotSec32 | 32 | 4 |
This field is the new 32-bit total count of sectors on the volume.
This count includes the count of all sectors in all four regions of the
volume. This field can be 0; if it is 0, then BPB_TotSec16 must be
non-zero. For FAT32 volumes, this field must be non-zero. For
FAT12/FAT16 volumes, this field contains the sector count if
BPB_TotSec16 is 0 (count is greater than or equal to 0x10000).
(This specifies that an unused BPB_TotSec32 field is set to zero.)
By the way fix offsets in include/grub/fat.h.
Tested with lDebug booted in qemu via grub2's
FreeDOS direct loading support, refer to
https://bitbucket.org/ecm/ldosboot + https://bitbucket.org/ecm/ldebug
Signed-off-by: C. Masloch <pushbx@38.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Previously we had multiboot and multiboot2 declaring the same symbols.
This can potentially lead to aliasing and strange behaviours when e.g.
module instead of module2 is used with multiboot2.
Bug: #51137
In util/getroot and efidisk slightly modify exitsing comment to mostly
retain it but still make GCC7 compliant with respect to fall through
annotation.
In grub-core/lib/xzembed/xz_dec_lzma2.c it adds same comments as
upstream.
In grub-core/tests/setjmp_tets.c declare functions as "noreturn" to
suppress GCC7 warning.
In grub-core/gnulib/regexec.c use new __attribute__, because existing
annotation is not recognized by GCC7 parser (which requires that comment
immediately precedes case statement).
Otherwise add FALLTHROUGH comment.
Closes: 50598
In case of GRUB we put remapper after domain pages and not at 0x0.
In this case we use max_addr to put remapper. Unfortunately we increment
max_addr as well in this case resulting in virt mapping mapping page
at old max_addr and trying to boot using new max_addr.
Closes 46014.
Modern pvops linux kernels support a p2m list not covered by the
kernel mapping. This capability is flagged by an elf-note specifying
the virtual address the kernel is expecting the p2m list to be mapped
to.
In case the elf-note is set by the kernel don't place the p2m list
into the kernel mapping, but map it to the given address. This will
allow to support domains with larger memory, as the kernel mapping is
limited to 2GB and a domain with huge memory in the TB range will have
a p2m list larger than this.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Modify the page table construction to allow multiple virtual regions
to be mapped. This is done as preparation for removing the p2m list
from the initial kernel mapping in order to support huge pv domains.
This allows a cleaner approach for mapping the relocator page by
using this capability.
The interface to the assembler level of the relocator has to be changed
in order to be able to process multiple page table areas.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Modern pvops linux kernels support an initrd not covered by the initial
mapping. This capability is flagged by an elf-note.
In case the elf-note is set by the kernel don't place the initrd into
the initial mapping. This will allow to load larger initrds and/or
support domains with larger memory, as the initial mapping is limited
to 2GB and it is containing the p2m list.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Do the allocation of page tables in a separate function. This will
allow to do the allocation at different times of the boot preparations
depending on the features the kernel is supporting.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Do the allocation of special pages (start info, console and xenbus
ring buffers) in a separate function. This will allow to do the
allocation at different times of the boot preparations depending on
the features the kernel is supporting.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Do the p2m list allocation of the to be loaded kernel in a separate
function. This will allow doing the p2m list allocation at different
times of the boot preparations depending on the features the kernel
is supporting.
While at this remove superfluous setting of first_p2m_pfn and
nr_p2m_frames as those are needed only in case of the p2m list not
being mapped by the initial kernel mapping.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Various features and parameters of a pv-kernel are specified via
elf notes in the kernel image. Those notes are part of the interface
between the Xen hypervisor and the kernel.
Instead of using num,bers in the code when interpreting the elf notes
make use of the header supplied by Xen for that purpose.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The loader for xen paravirtualized environment is using lots of global
variables. Reduce the number by making them either local or by putting
them into a single state structure.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When loading a Xen pv-kernel avoid memory leaks in case of errors.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The loader for xen paravirtualized environment isn't callable multiple
times as it won't free any memory in case of failure.
Call grub_relocator_unload() as other modules do it before allocating
a new relocator or when unloading the module.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Currently multiboot2 protocol loads image exactly at address specified in
ELF or multiboot2 header. This solution works quite well on legacy BIOS
platforms. It is possible because memory regions are placed at predictable
addresses (though I was not able to find any spec which says that it is
strong requirement, so, it looks that it is just a goodwill of hardware
designers). However, EFI platforms are more volatile. Even if required
memory regions live at specific addresses then they are sometimes simply
not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
OVMF). This means that you are not able to just set up final image
destination on build time. You have to provide method to relocate image
contents to real load address which is usually different than load address
specified in ELF and multiboot2 headers.
This patch provides all needed machinery to do self relocation in image code.
First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load addr),
align (required image alignment), preference (it says which memory regions are
preferred by image, e.g. none, low, high) from multiboot_header_tag_relocatable
header tag contained in binary (at this stage load addresses from multiboot2
and/or ELF headers are ignored). Later loader tries to fulfill request (not only
that one) and if it succeeds then it informs image about real load address via
multiboot_tag_load_base_addr tag. At this stage GRUB2 role is finished. Starting
from now executable must cope with relocations itself using whole static and
dynamic knowledge provided by boot loader.
This patch does not provide functionality which could do relocations using
ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and Vladimir
'phcoder' Serbinenko to investigate that thing. It looks that relevant machinery
could be added to existing code (including this patch) without huge effort.
Additionally, ELF relocation could live in parallel with self relocation provided
by this patch. However, during research I realized that first of all we should
establish the details how ELF relocatable image should look like and how it should
be build. At least to build proper test/example files.
So, this patch just provides support for self relocatable images. If ELF file
with relocs is loaded then GRUB2 complains loudly and ignores it. Support for
such files will be added later.
This patch was tested with Xen image which uses that functionality. However, this Xen
feature is still under development and new patchset will be released in about 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
