coreboot has ACPI while 2 others don't. *BSD need ACPI and have trouble
without it. Don't even attempt to boot *BSD on multiboot or qemu targets.
On coreboot boot all *BSD except 32-bit NetBSD which apparently does some
early BIOS calls.
We want a single buffer that contains the entire kernel image in order to
perform a TPM measurement. Allocate one and copy the entire kernel int it
before pulling out the individual blocks later on.
We want a single buffer that contains the entire kernel image in order to
perform a TPM measurement. Allocate one and copy the entire kernel into it
before pulling out the individual blocks later on.
Add support for performing basic TPM measurements. Right now this only
supports extending PCRs statically and only on UEFI and BIOS systems, but
will measure all modules as they're loaded.
The Secure Boot code currently reads the kernel from disk, validates the
signature and then reads it from disk again. A sufficiently exciting storage
device could modify the kernel between these two events and trigger the
execution of an untrusted kernel. Avoid re-reading it in order to ensure
this isn't a problem, and in the process speed up boot by not reading the
kernel twice.
efiemu is supposed to be disabled when compiling through exe format.
Unfortunately format was determined only after efiemu check. Reorder to fix the
problem
On emu some checks can be laxer like check for relocation range. Additionally
module loading in emu is rarely used. So skip this check rather than making
it laxer for all platforms. In ideal we may want to have slightly different
check for emu but for now this is good enough.
This argument disables generation of calls to __chkstk_ms. Those calls are
useless on GRUB as function is dummy. Yet they increase module size and
use limited-range relocations which may not work under some memory layouts.
We currently don't use such layouts on concerned platforms but lt's correct
this.
This section is generated by clang and is useful only for debugging.
It contains exotic relocations, so strip them to avoid them interferring
with module loading.
Currently only Windows gets distinguished icons, everything else is displayed
using the same generic one. Add additional --class based on os-prober returned
label, which usually is expected to match primary distribution name.
Also use it for Windows as well - chainloader prober may actually return
different strings (Windows, MS-DOS, Windows9xME).
This was lost when code was refactored. Patch restores previous behavior.
It is still not clear whether this is the right one. Due to the way we
detect DM abstraction, partitions on DM are skipped, we fall through to
generic detection which ends up in assuming parent device is BIOS disk.
It is useful to install GRUB on VM disk from the host. But it also means
that GRUB will mistakenly allow install on real system as well.
For now let's fix regression; future behavior needs to be discussed.
Closes: 45163
GRUB keeps partition offset and size in units of 512B sectors. Media paths
are defined in terms of LBA which are presumed to match HDD sector size.
This is probably cosmetic (EFI requires that partition is searched by GUID)
and still incorrect if GPT was created using different logical block size.
But current code is obviously wrong and new has better chances to be correct.
