The CRC implementation imported from libgcrypt 1.5.3 is arguably
non-free, due to being encumbered by the restrictive Internet Society
licence on RFCs (see e.g. https://wiki.debian.org/NonFreeIETFDocuments).
Fortunately, libgcrypt has since replaced it with a version that is both
reportedly better-optimised and doesn't suffer from this encumbrance.
The ideal solution would be to update to a new version of libgcrypt, and
I spent some time trying to do that. However, util/import_gcry.py
requires complex modifications to cope with the new version, and I
stalled part-way through; furthermore, GRUB's libgcrypt tree already
contains some backports of upstream changes. Rather than allowing the
perfect to be the enemy of the good, I think it's best to backport this
single change to at least sort out the licensing situation. Doing so
won't make things any harder for a future wholesale upgrade.
This commit is mostly a straightforward backport of
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=06e122baa3321483a47bbf82fd2a4540becfa0c9,
but I also imported bufhelp.h from libgcrypt 1.7.0 (newer versions
required further changes elsewhere).
I've tested that "hashsum -h crc32" still produces correct output for a
variety of files on both i386-pc and x86_64-emu targets.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The reboot function calls machine_fini() and then reboots the system.
Currently it lives in lib/ which means it gets compiled into the
reboot module which lives on the heap.
In a following patch, I want to free the heap on machine_fini()
though, so we would free the memory that the code is running in. That
obviously breaks with smarter UEFI implementations.
So this patch moves it into the core. That way we ensure that all
code running after machine_fini() in the UEFI case is running from
memory that got allocated (and gets deallocated) by the UEFI core.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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
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>
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>
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>
Writing the primary GPT before the backup may lead to a confusing
situation: booting a freshly updated system could consistently fail and
next boot will fall back to the old system if writing the primary works
but writing the backup fails. If the backup is written first and fails
the primary is left in the old state so the next boot will re-try and
possibly fail in the exact same way. Making that repeatable should make
it easier for users to identify the error.
Additionally if the firmware and OS disagree on the disk size, making
the backup inaccessible to GRUB, then just skip writing the backup.
When this happens the automatic call to `coreos-setgoodroot` after boot
will take care of repairing the backup.
The firmware and the OS may disagree on the disk configuration and size.
Although such a setup should be avoided users are unlikely to know about
the problem, assuming everything behaves like the OS. Tolerate this as
best we can and trust the reported on-disk location over the firmware
when looking for the backup GPT. If the location is inaccessible report
the error as best we can and move on.
I personally think this reads easier. Also has the side effect of
directly comparing the primary and backup tables instead of presuming
they are equal if the crc32 matches.
This ensures all code modifying GPT data include the same sanity check
that repair does. If revalidation fails the status flags are left in the
appropriate state.
The header was being relocated without checking the new location is
actually safe. If the BIOS thinks the disk is smaller than the OS then
repair may relocate the header into allocated space, failing the final
validation check. So only move it if the disk has grown.
Additionally, if the backup is valid then we can assume its current
location is good enough and leave it as-is.
Use the new status function which checks *_HEADER_VALID and
*_ENTRIES_VALID bits together. It doesn't make sense for the header and
entries bits to mismatch so don't allow for it.
Portions of the code attempted to handle the fact that GPT entries on
disk may be larger than the currently defined struct while others
assumed the data could be indexed by the struct size directly. This
never came up because no utility uses a size larger than 128 bytes but
for the sake of safety we need to do this by the spec.
GPT_BOTH_VALID is 4 bits so simple a boolean check is not sufficient.
This broken condition allowed gptprio to trust bogus disk locations in
headers that were marked invalid causing arbitrary disk corruption.
GRUB assumes that no disk is ever larger than 1EiB and rejects
reads/writes to such locations. Unfortunately this is not conveyed in
the usual way with the special GRUB_DISK_SIZE_UNKNOWN value.
Rework TPM measurements to use fewer PCRs. After discussion with upstream,
it's preferable to avoid using so many PCRs. Instead, measure into PCRs 8
and 9 but use a prefix in the event log to indicate which subsystem carried
out the measurements.
-Wunreachable-code has been a no-op since GCC 4.5; GRUB hasn't been
compiled with it since 2012; and GCC 6 produces "error:
'-Wunreachable-code' is not an option that controls warnings" for these.
Fixes Debian bug #812047.
