According to the System V Application Binary Interface specification [1]
the sections holding a symbol table, SHT_SYMTAB and SHT_DYNSYM, have to
have sh_info set to "One greater than the symbol table index of the last
local symbol (binding STB_LOCAL)". Current code converting PE images to
ELF files does not do that and readelf complains in following way:
...
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 000034 0014d4 00 AX 0 0 4
[ 2] .data PROGBITS 00000000 001508 000040 00 WA 0 0 32
[ 3] .rdata PROGBITS 00000000 001548 0006b8 00 A 0 0 4
[ 4] .module_license PROGBITS 00000000 001c00 000010 00 0 0 4
[ 5] .bss NOBITS 00000000 000000 000008 00 WA 0 0 4
[ 6] .moddeps PROGBITS 00000000 001c10 000010 00 0 0 4
[ 7] .modname PROGBITS 00000000 001c20 000008 00 0 0 4
[ 8] .rel.text REL 00000000 001c28 0008c8 08 11 1 4
[ 9] .rel.data REL 00000000 0024f0 000040 08 11 2 4
[10] .rel.rdata REL 00000000 002530 000070 08 11 3 4
[11] .symtab SYMTAB 00000000 0025a0 0001d0 10 12 0 4
[12] .strtab STRTAB 00000000 002770 000237 00 0 0 1
...
Symbol table '.symtab' contains 29 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
readelf: Warning: local symbol 0 found at index >= .symtab's sh_info value of 0
1: 0000144a 0 FUNC LOCAL DEFAULT 1 grub_mod_init
readelf: Warning: local symbol 1 found at index >= .symtab's sh_info value of 0
2: 000014aa 0 FUNC LOCAL DEFAULT 1 grub_mod_fini
readelf: Warning: local symbol 2 found at index >= .symtab's sh_info value of 0
3: 00000000 0 SECTION LOCAL DEFAULT 1 .text
readelf: Warning: local symbol 3 found at index >= .symtab's sh_info value of 0
4: 00000000 0 SECTION LOCAL DEFAULT 2 .data
readelf: Warning: local symbol 4 found at index >= .symtab's sh_info value of 0
5: 00000000 0 SECTION LOCAL DEFAULT 5 .bss
readelf: Warning: local symbol 5 found at index >= .symtab's sh_info value of 0
6: 00000000 0 SECTION LOCAL DEFAULT 3 .rdata
readelf: Warning: local symbol 6 found at index >= .symtab's sh_info value of 0
7: 00000000 0 NOTYPE GLOBAL DEFAULT UND grub_dma_get_phys
8: 00000000 0 NOTYPE GLOBAL DEFAULT UND grub_cs5536_write_msr
9: 00000000 0 NOTYPE GLOBAL DEFAULT UND grub_dma_free
...
Let's fix it...
[1] https://www.sco.com/developers/gabi/2012-12-31/contents.html
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Alec Brown <alec.r.brown@oracle.com>
The commit 98ad84328 (kern/dl: Check for the SHF_INFO_LINK flag in
grub_dl_relocate_symbols()) revealed a bug in the code converting PE
module images to ELF files. The missing SHF_INFO_LINK flag for SHT_REL
and SHT_RELA sections lead to hangs during GRUB load. This only happens
for the GRUB images generated on Windows platforms. The *NIX platforms
are not affected due to lack of PE to ELF conversion step.
This patch fixes the issue...
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Alec Brown <alec.r.brown@oracle.com>
This file was not added to EXTRA_DIST during the appended signatures merge.
Fixes: 3e4ff6ffb (appended signatures: Parse ASN1 node)
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Alec Brown <alec.r.brown@oracle.com>
Currently bootstrap complains in the following way when
patching gnulib files:
patching file regcomp.c
Hunk #2 succeeded at 1029 with fuzz 2.
Hunk #5 succeeded at 1716 with fuzz 2.
patching file regexec.c
patching file base64.c
patching file regexec.c
Hunk #1 succeeded at 807 (offset -21 lines).
Let's fix it by adding missing "\f" and amending line
numbers in the patches.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Alec Brown <alec.r.brown@oracle.com>
This fixes naming inconsistency that goes against coding style as well
as helps to avoid potential conflicts and confusion as this constant is
used in multiple places.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Currently rdmsr and wrmsr commands have own MSR support detection code.
This code is the same. So, it is duplicated. Additionally, this code
cannot be reused by others. Hence, extract this code to a function and
make it public. By the way, improve a code a bit.
Additionally, use GRUB_ERR_BAD_DEVICE instead of GRUB_ERR_BUG to signal
an error because errors encountered by this new routine are not bugs.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Otherwise the GRUB cannot start due to missing symbols when stack
protector is enabled on EFI platforms.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
The LoadImage() provided by the shim does not consult MOK when loading
an image. So, simply signature verification fails when it should not.
This means we cannot use Linux EFI stub to start the kernel when the
shim is loaded. We have to fallback to legacy mode on x86 architectures.
This is not possible on other architectures due to lack of legacy mode.
This is workaround which should disappear when the shim provides
LoadImage() which looks up MOK during signature verification.
On the occasion align constants in include/grub/efi/sb.h.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
... because (surprisingly) it does not use specific EFI calling convention...
Fixes: 6a080b9cd (efi: Add calling convention annotation to all prototypes)
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Most of leftover code blindly assumes GRUB_RELOCATOR_FIRMWARE_REQUESTS_QUANT
divisibility by 8. So, enforce this at compile time.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Currently bootstrap complains in the following way when
patching gnulib files:
patching file argp-help.c
Hunk #1 succeeded at 52 (offset 1 line).
Hunk #2 succeeded at 1548 (offset 115 lines).
patching file mbswidth.c
patching file mbswidth.h
Hunk #1 succeeded at 40 (offset -5 lines).
Let's fix it by amending line numbers in the patch.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Alec Brown <alec.r.brown@oracle.com>
The commit bb4aa6e06 (efi: Drop all uses of efi_call_XX() wrappers) did
not add some __grub_efi_api attributes to the EFI calls. Lack of them
led to hangs on x86_64-efi target. So, let's add missing __grub_efi_api
attributes.
Fixes: bb4aa6e06 (efi: Drop all uses of efi_call_XX() wrappers)
Reported-by: Christian Hesse <list@eworm.de>
Reported-by: Robin Candau <antiz@archlinux.org>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Robin Candau <antiz@archlinux.org>
Tested-by: Christian Hesse <list@eworm.de>
Reviewed-by: Peter Jones <pjones@redhat.com>
$ ./configure --target=x86_64-w64-mingw32 --with-platform=efi --host=x86_64-w64-mingw32
$ make
[...]
cat syminfo.lst | sort | gawk -f ./genmoddep.awk > moddep.lst || (rm -f moddep.lst; exit 1)
__imp__errno in regexp is not defined
This happens because grub-core/lib/gnulib/malloc/dynarray_resize.c and
grub-core/lib/gnulib/malloc/dynarray_emplace_enlarge.c (both are used by
regexp module) from the latest Gnulib call __set_errno() which originally
sets errno variable (Windows builds add __imp__ prefix). Of course it is
not defined and grub_errno should be used instead.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The mingw-w64-tools is especially important because with out it some
Windows builds may fail due to lack of proper pkg-config.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
These are probably stray references left after earlier removals.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
$ ./configure --target=i686-w64-mingw32 --with-platform=efi --host=i686-w64-mingw32
[...]
checking if __bss_start is defined by the compiler... no
checking if edata is defined by the compiler... no
checking if _edata is defined by the compiler... no
configure: error: none of __bss_start, edata or _edata is defined
This happens on machines with quite recent ld due to an error:
`edata' referenced in section `.text' of /tmp/cc72w9E4.o: defined in discarded section `.data' of conftest.exe
collect2: error: ld returned 1 exit status
So, we have to tell linker to not discard .data and .edata sections.
The trick comes from ld documentation:
3.6.7 Output Section Discarding
The linker will not normally create output sections with no contents.
This is for convenience when referring to input sections that may or may
not be present in any of the input files. For example:
.foo : { *(.foo) }
will only create a ‘.foo’ section in the output file if there is a
‘.foo’ section in at least one input file, and if the input sections are
not all empty. Other link script directives that allocate space in an
output section will also create the output section. So too will
assignments to dot even if the assignment does not create space, except
for ‘. = 0’, ‘. = . + 0’, ‘. = sym’, ‘. = . + sym’ and ‘. = ALIGN (. !=
0, expr, 1)’ when ‘sym’ is an absolute symbol of value 0 defined in the
script. This allows you to force output of an empty section with ‘. = .’.
This change does not impact generated binaries because the
conf/i386-cygwin-img-ld.sc linker script is used only when
you run configure.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
Latest GCC may complain in that way:
commands/i386/pc/sendkey.c: In function ‘grub_sendkey_postboot’:
commands/i386/pc/sendkey.c:223:21: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
223 | *((char *) 0x41a) = 0x1e;
| ~~~~~~~~~~~~~~~~~~^~~~~~
The volatile keyword addition helps and additionally assures us the
compiler will not optimize out fixed assignments.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
Latest GCC may complain in that way:
In file included from ../include/grub/disk.h:31,
from ../include/grub/file.h:26,
from ../include/grub/loader.h:23,
from loader/i386/bsd.c:19:
loader/i386/bsd.c: In function ‘grub_cmd_openbsd’:
../include/grub/misc.h:71:10: error: ‘ptr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
71 | return grub_memmove (dest, src, n);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
loader/i386/bsd.c:266:9: note: ‘ptr’ was declared here
266 | void *ptr;
| ^~~
So, let's fix it by assigning NULL to ptr in grub_bsd_add_meta().
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
$ ./configure --target=x86_64-w64-mingw32 --with-platform=efi --host=x86_64-w64-mingw32
$ make
[...]
In file included from grub-core/osdep/platform.c:4:
grub-core/osdep/windows/platform.c: In function ‘grub_install_register_efi’:
grub-core/osdep/windows/platform.c:382:41: error: taking address of packed member of ‘struct grub_efi_file_path_device_path’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
382 | path16_len = grub_utf8_to_utf16 (filep->path_name,
| ~~~~~^~~~~~~~~~~
Disable the -Wadress-of-packaed-member diagnostic for grub_utf8_to_utf16()
call which contains filep->path_name reference. It seems safe because the
structure is defined according to the UEFI spec and we hope authors did not
make any mistake... :-)
This fix is similar to the fix in the commit 8e8723a6b
(f2fs: Disable gcc9 -Waddress-of-packed-member).
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
Skip versions between 2.07 and 2.10 to avoid leading zeros in minor
version number. This way version parsing in scripts should be easier.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Additionally, fix the terminfo spelling mistake in
the GRUB development documentation.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
This is an additional fix which has been missing from the commit 837fe48de
(i18n: Format large integers before the translation message).
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Two grub_device_open() calls does not have associated NULL checks
for returned values. Fix that and appease the Coverity.
Fixes: CID 314583
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Now that the GRUB has a grub_efi_get_secureboot() function to check the
UEFI Secure Boot status, use it to report that to the Linux kernel.
Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Marco A Benatto <mbenatto@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It will be used to properly detect and report UEFI Secure Boot status to
the x86 Linux kernel. The functionality will be added by subsequent patches.
Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Marco A Benatto <mbenatto@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This is needed to properly detect and report UEFI Secure Boot status
to the x86 Linux kernel. The functionality will be added by subsequent
patches.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Marco A Benatto <mbenatto@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The GUID will be used to properly detect and report UEFI Secure Boot
status to the x86 Linux kernel. The functionality will be added by
subsequent patches. The shim_lock protocol type is made public for
completeness.
Additionally, fix formatting of four preceding GUIDs.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Marco A Benatto <mbenatto@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Rename get_active_pcr_blanks() to get_active_pcr_banks().
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
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>
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>
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>
..to reflect the GRUB build reality in them.
Additionally, fix text formatting a bit.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
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>
Lack of them causes random instructions to be executed before the
jump really happens.
Signed-off-by: Vladimir Serbinenko <phcoder@google.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>
Some older GCC versions produce following error when x86 MSR modules are build:
In file included from commands/i386/rdmsr.c:29:0:
../include/grub/i386/rdmsr.h:27:29: error: no previous prototype for ‘grub_msr_read’ [-Werror=missing-prototypes]
extern inline grub_uint64_t grub_msr_read (grub_uint32_t msr_id)
^
cc1: all warnings being treated as errors
This happens due to lack of support for a such usage of extern keyword
in older GCCs. Additionally, this usage is not consistent with the rest
of codebase. So, replace it with static keyword.
Additionally, fix incorrect coding style.
Reported-by: Eric Snowberg <eric.snowberg@oracle.com>
Reported-by: adrian15 <adrian15sgd@gmail.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
Reviewed-by: Eric Snowberg <eric.snowberg@oracle.com>
Tested-by: adrian15 <adrian15sgd@gmail.com>
Current comments forms are annoying, so, some of them are disallowed
starting from now. New rules are more flexible and mostly aligned
with, e.g., Linux kernel comments rules.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@google.com>
PowerPC fallout cleanup after commit 4d4a8c96e (verifiers: Add possibility
to verify kernel and modules command lines) and 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>
ARM 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>
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>
This module provides shim lock verification for various kernels
if UEFI secure boot is enabled on a machine.
It is recommended to put this module into GRUB2 standalone image
(avoid putting iorw and memrw modules into it; they are disallowed
if UEFI secure boot is enabled). However, it is also possible to use
it as a normal module. Though such configurations are more fragile
and less secure due to various limitations.
If the module is loaded and UEFI secure boot is enabled then:
- module itself cannot be unloaded (persistent module),
- the iorw and memrw modules cannot be loaded,
- if the iorw and memrw modules are loaded then
machine boot is disabled,
- GRUB2 defers modules and ACPI tables verification to
other verifiers.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
This type of modules cannot be unloaded. This is useful if a given
functionality, e.g. UEFI secure boot shim signature verification, should
not be disabled if it was enabled at some point in time. Somebody may
say that we can use standalone GRUB2 here. That is true. However, the
code is not so big nor complicated hence it make sense to support
modularized configs too.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
This way if a verifier requires verification of a given file it can defer task
to another verifier (another authority) if it is not able to do it itself. E.g.
shim_lock verifier, posted as a subsequent patch, is able to verify only PE
files. This means that it is not able to verify any of GRUB2 modules which have
to be trusted on UEFI systems with secure boot enabled. So, it can defer
verification to other verifier, e.g. PGP one.
I silently assume that other verifiers are trusted and will do good job for us.
Or at least they will not do any harm.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
The sparse inode metadata format became a mkfs.xfs default in
xfsprogs-4.16.0, and such filesystems are now rejected by grub as
containing an incompatible feature.
In essence, this feature allows xfs to allocate inodes into fragmented
freespace. (Without this feature, if xfs could not allocate contiguous
space for 64 new inodes, inode creation would fail.)
In practice, the disk format change is restricted to the inode btree,
which as far as I can tell is not used by grub. If all you're doing
today is parsing a directory, reading an inode number, and converting
that inode number to a disk location, then ignoring this feature
should be fine, so I've added it to XFS_SB_FEAT_INCOMPAT_SUPPORTED
I did some brief testing of this patch by hacking up the regression
tests to completely fragment freespace on the test xfs filesystem, and
then write a large-ish number of inodes to consume any existing
contiguous 64-inode chunk. This way any files the grub tests add and
traverse would be in such a fragmented inode allocation. Tests passed,
but I'm not sure how to cleanly integrate that into the test harness.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Chris Murphy <lists@colorremedies.com>
IEEE 1275-1994 Standard for Boot (Initialization Configuration)
Firmware: Core Requirements and Practices
E.3.2.2 Bus-specific methods for bus nodes
A package implementing the scsi-2 device type shall implement the
following bus-specific method:
no-data-command ( cmd-addr -- error? )
Executes a simple SCSI command, automatically retrying under
certain conditions. cmd-addr is the address of a 6-byte command buffer
containing an SCSI command that does not have a data transfer phase.
Executes the command, retrying indefinitely with the same retry criteria
as retry-command.
error? is nonzero if an error occurred, zero otherwise.
NOTE no-data-command is a convenience function. It provides
no capabilities that are not present in retry-command, but for
those commands that meet its restrictions, it is easier to use.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
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>
Unified Extensible Firmware Interface Specification, Version 2.6,
section 2.3.4, x64 Platforms, boot services, says among others:
The stack must be 16-byte aligned. So, do it. Otherwise OS may
boot only by chance as it happens right now.
Signed-off-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>
If image requested EFI boot services then skip multiboot2 memory maps.
Main reason for not providing maps is because they will likely be
invalid. We do a few allocations after filling them, e.g. for relocator
needs. Usually we do not care as we would have finished boot services.
If we keep boot services then it is easier/safer to not provide maps.
However, if image needs memory maps and they are not provided by bootloader
then it should get itself just before ExitBootServices() call.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Add tags used to pass ImageHandle to loaded image if requested.
It is used by at least ExitBootServices() function.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. Relocator
will set lower parts of %rax and %rbx accordingly to multiboot2 specification.
On the other hand processor mode, just before jumping into loaded image, will
be set accordingly to Unified Extensible Firmware Interface Specification,
Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services. This way
loaded image will be able to use EFI boot services without any issues.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Daniel Kiper