In order to be able to read from and write to model-specific registers,
two new modules are added. They are i386 specific, as the cpuid module.
rdmsr module registers the command rdmsr that allows reading from a MSR.
wrmsr module registers the command wrmsr that allows writing to a MSR.
wrmsr module is disabled if UEFI secure boot is enabled.
Please note that on SMP systems, interacting with a MSR that has a scope
per hardware thread, implies that the value only applies to the
particular cpu/core/thread that ran the command.
Also, if you specify a reserved or unimplemented MSR address, it will
cause a general protection exception (which is not currently being
handled) and the system will reboot.
Signed-off-by: Jesús Diéguez Fernández <jesusdf@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In order to maintain the coding style consistency, it was requested to
replace the methods that use "__asm__ __volatile__" with "asm volatile".
Signed-off-by: Jesús Diéguez Fernández <jesusdf@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add a new disk driver called obdisk for IEEE1275 platforms. Currently
the only platform using this disk driver is SPARC, however other IEEE1275
platforms could start using it if they so choose. While the functionality
within the current IEEE1275 ofdisk driver may be suitable for PPC and x86, it
presented too many problems on SPARC hardware.
Within the old ofdisk, there is not a way to determine the true canonical
name for the disk. Within Open Boot, the same disk can have multiple names
but all reference the same disk. For example the same disk can be referenced
by its SAS WWN, using this form:
/pci@302/pci@2/pci@0/pci@17/LSI,sas@0/disk@w5000cca02f037d6d,0
It can also be referenced by its PHY identifier using this form:
/pci@302/pci@2/pci@0/pci@17/LSI,sas@0/disk@p0
It can also be referenced by its Target identifier using this form:
/pci@302/pci@2/pci@0/pci@17/LSI,sas@0/disk@0
Also, when the LUN=0, it is legal to omit the ,0 from the device name. So with
the disk above, before taking into account the device aliases, there are 6 ways
to reference the same disk.
Then it is possible to have 0 .. n device aliases all representing the same disk.
Within this new driver the true canonical name is determined using the the
IEEE1275 encode-unit and decode-unit commands when address_cells == 4. This
will determine the true single canonical name for the device so multiple ihandles
are not opened for the same device. This is what frequently happens with the old
ofdisk driver. With some devices when they are opened multiple times it causes
the entire system to hang.
Another problem solved with this driver is devices that do not have a device
alias can be booted and used within GRUB. Within the old ofdisk, this was not
possible, unless it was the original boot device. All devices behind a SAS
or SCSI parent can be found. Within the old ofdisk, finding these disks
relied on there being an alias defined. The alias requirement is not
necessary with this new driver. It can also find devices behind a parent
after they have been hot-plugged. This is something that is not possible
with the old ofdisk driver.
The old ofdisk driver also incorrectly assumes that the device pointing to by a
device alias is in its true canonical form. This assumption is never made with
this new driver.
Another issue solved with this driver is that it properly caches the ihandle
for all open devices. The old ofdisk tries to do this by caching the last
opened ihandle. However this does not work properly because the layer above
does not use a consistent device name for the same disk when calling into the
driver. This is because the upper layer uses the bootpath value returned within
/chosen, other times it uses the device alias, and other times it uses the
value within grub.cfg. It does not have a way to figure out that these devices
are the same disk. This is not a problem with this new driver.
Due to the way GRUB repeatedly opens and closes the same disk. Caching the
ihandle is important on SPARC. Without caching, some SAS devices can take
15 - 20 minutes to get to the GRUB menu. This ihandle caching is not possible
without correctly having the canonical disk name.
When available, this driver also tries to use the deblocker #blocks and
a way of determining the disk size.
Finally and probably most importantly, this new driver is also capable of
seeing all partitions on a GPT disk. With the old driver, the GPT
partition table can not be read and only the first partition on the disk
can be seen.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Many of GRUB's utilities don't check anywhere near all the possible
write errors. For example, if grub-install runs out of space when
copying a file, it won't notice. There were missing checks for the
return values of write, fflush, fsync, and close (or the equivalents on
other OSes), all of which must be checked.
I tried to be consistent with the existing logging practices of the
various hostdisk implementations, but they weren't entirely consistent
to start with so I used my judgement. The result at least looks
reasonable on GNU/Linux when I provoke a write error:
Installing for x86_64-efi platform.
grub-install: error: cannot copy `/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed' to `/boot/efi/EFI/debian/grubx64.efi': No space left on device.
There are more missing checks in other utilities, but this should fix
the most critical ones.
Fixes Debian bug #922741.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Steve McIntyre <93sam@debian.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Much like on x86, we can work out if the system is running on top of EFI
firmware. If so, return "arm-efi". If not, fall back to "arm-uboot" as
previously.
Split out the code to (maybe) load the efivar module and check for
/sys/firmware/efi into a common helper routine is_efi_system().
Signed-off-by: Steve McIntyre <93sam@debian.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This reverts commit 082fd84d52.
Incorrect version of the patch was pushed into the git repo.
Reported-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Much like on x86, we can work out if the system is running on top
of EFI firmware. If so, return "arm-efi". If not, fall back to
"arm-uboot" as previously.
Heavily inspired by the existing code for x86.
Signed-off-by: Steve McIntyre <93sam@debian.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
We now have signature check logic in grub which allows us to treat
files differently depending on their file type.
Treat a loaded device tree like an overlayed ACPI table.
Both describe hardware, so I suppose their threat level is the same.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
This patch adds support for RISC-V to the grub build system. With this
patch, I can successfully build grub on RISC-V as a UEFI application.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Gcc may decide it wants to call helper functions to execute clz. Provide
them in our own copy of libgcc.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
To support a new architecture we need to provide a few helper functions
for memory, cache, timer, etc support.
This patch adds the remainders of those. Some bits are still disabled,
as I couldn't guarantee that we're always running on models / in modes
where the respective hardware is available.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch adds awareness of RISC-V relocations throughout the grub tools
as well as dynamic linkage and elf->PE relocation conversion support.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
We currently only support to run grub on RISC-V as UEFI payload. Ideally,
we also only want to support running Linux underneath as UEFI payload.
Prepare that with some Linux boot stub code. Once the arm64 target is
generalized, we can hook into that one and gain boot functionality.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch adds a 32/64 capable setjmp implementation for RISC-V.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The RISC-V ABI document outlines ELF header structure and relocation
information. Pull the respective magic numbers into our elf header
so we can make use of them.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The PE format defines magic numbers as well as relocation identifiers for
RISC-V. Add them to our include file, so we can make use of them.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Some architectures want to boot Linux as plain UEFI binary. Today that
really only encompasses ARM and AArch64, but going forward more
architectures may adopt that model.
So rename our internal API accordingly.
Signed-off-by: Alexander Graf <agraf@suse.de>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
There is UEFI firmware popping up in the wild now that implements stricter
permission checks using NX and write protect page table entry bits.
This means that firmware now may fail to load binaries if its individual
sections are not page aligned, as otherwise it can not ensure permission
boundaries.
So let's bump all efi section alignments up to 4k (EFI page size). That way
we will stay compatible going forward.
Unfortunately our internals can't deal very well with a mismatch of alignment
between the virtual and file offsets, so we have to also pad our target
binary a bit.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Julien ROBIN <julien.robin28@free.fr>
This patch allows to have bigger kernels. If the kernel grows, then it will
overwrite the initrd when it is extracted.
Signed-off-by: Guillaume GARDET <guillaume.gardet@arm.com>
Acked-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A certain amount of dynamic space is required for the handover from
GRUB/Linux-EFI-stub. This entails things like initrd addresses,
address-cells entries and associated strings.
But move this into a proper centralised #define rather than live-code
it in the loader.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
uboot_disk_write() is currently lacking the write support
to storage devices because, historically, those devices did not
implement block_write() in U-Boot.
The solution has been tested using a patched U-Boot loading
and booting GRUB in a QEMU vexpress-a9 environment.
The disk write operations were triggered with GRUB's save_env
command.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add support for performing basic TPM measurements. Right now this only
supports extending PCRs statically and only on UEFI. In future we might
want to have some sort of mechanism for choosing which events get logged
to which PCRs, but this seems like a good default policy and we can wait
to see whether anyone has a use case before adding more complexity.
Signed-off-by: Matthew Garrett <mjg59@google.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Pass all commands executed by GRUB to the verifiers layer. Most verifiers will
ignore this, but some (such as the TPM verifier) want to be able to measure and
log each command executed in order to ensure that the boot state is as expected.
Signed-off-by: Matthew Garrett <mjg59@google.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add xen_pvh support to grub-install.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Support mkimage for xen_pvh.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Add the needed code to setup the hypercall page for calling into the
Xen hypervisor.
Import the XEN_HVM_DEBUGCONS_IOPORT define from Xen unstable into
include/xen/arch-x86/xen.h
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
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>
include/grub/offsets.h needs some defines for Xen PVH mode.
Add them. While at it line up the values in the surrounding lines to
start at the same column.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
With Xen PVH mode adding a new machine type the machine related headers
need to be present for the build to succeed. Most of the headers just
need to include the related common i386 headers. Add those to the tree.
Note that xen_pvh/int.h needs to include pc/int_types.h instead of
pc/int.h in order to avoid the definition of grub_bios_interrupt().
xen_pvh/memory.h needs to include coreboot/memory.h (like some other
<machine>/memory.h do as well) as this contains just the needed stubs.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Some common code needs to be special cased for Xen PVH mode. This hits
mostly Xen PV mode specific areas.
Split include/grub/i386/pc/int_types.h off from
include/grub/i386/pc/int.h to support including this file later from
xen_pvh code without the grub_bios_interrupt definition.
Move definition of struct grub_e820_mmap_entry from
grub-core/mmap/i386/pc/mmap.c to include/grub/i386/memory.h in order
to make it usable from xen_pvh code.
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>
In order to support grub2 in Xen PVH environment some additional Xen
headers are needed as grub2 will be started in PVH mode requiring to
use several HVM hypercalls and structures.
Add the needed headers from Xen 4.10 being the first Xen version with
full (not only experimental) PVH guest support.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
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>
An error emerged as when I was testing the verifiers branch, so instead
of putting it in pgp prefix, the verifiers is used to reflect what the
patch is based on.
While running verify_detached, grub aborts with error.
verify_detached /@/.snapshots/1/snapshot/boot/grub/grub.cfg
/@/.snapshots/1/snapshot/boot/grub/grub.cfg.sig
alloc magic is broken at 0x7beea660: 0
Aborted. Press any key to exit.
The error is caused by sig file descriptor been closed twice, first time
in grub_verify_signature() to which it is passed as parameter. Second in
grub_cmd_verify_signature() or in whichever opens the sig file
descriptor. The second close is not consider as bug to me either, as in
common rule of what opens a file has to close it to avoid file
descriptor leakage.
After all the design of grub_verify_signature() makes it difficult to keep
a good trace on opened file descriptor from it's caller. Let's refine
the application interface to accept file path rather than descriptor, in
this way the caller doesn't have to care about closing the descriptor by
delegating it to grub_verify_signature() with full tracing to opened
file descriptor by itself.
Also making it clear that sig descriptor is not referenced in error
returning path of grub_verify_signature_init(), so it can be closed
directly by it's caller. This also makes delegating it to
grub_pubkey_close() infeasible to help in relieving file descriptor
leakage as it has to depend on uncertainty of ctxt fields in error
returning path.
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The API change of grub_file_open() for adding verifiers did not include
a type for device tree blobs. Add GRUB_FILE_TYPE_DEVICE_TREE_IMAGE to
the grub_file_type enum.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
verify.h was added without include guards. This means compiling anything
including both include/grub/verify.h and include/grub/lib/cmdline.h fails
(at least grub-core/loader/arm64/linux.c.
Add the necessary include guard.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@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>
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>
Verifiers framework provides core file verification functionality which
can be used by various security mechanisms, e.g., UEFI secure boot, TPM,
PGP signature verification, etc.
The patch contains PGP code changes and probably they should be extracted
to separate patch for the sake of clarity.
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>
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>
The original code which handles the recovery of a RAID 6 disks array
assumes that all reads are multiple of 1 << GRUB_DISK_SECTOR_BITS and it
assumes that all the I/O is done via the struct grub_diskfilter_segment.
This is not true for the btrfs code. In order to reuse the native
grub_raid6_recover() code, it is modified to not call
grub_diskfilter_read_node() directly, but to call an handler passed
as an argument.
Signed-off-by: Goffredo Baroncelli <kreijack@inwind.it>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Make it so that when grub-module-verifier complains of an issue, it tells you
which module the issue was with.
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The 32-bit arm efi port now shares the 64-bit linux loader, so delete
the now unused bits from the 32-bit linux loader.
This in turn leaves the grub-core/kern/arm/efi/misc.c unused, so
delete that too.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The arm64 and arm linux kernel EFI-stub support presents pretty much
identical interfaces, so the same linux loader source can be used for
both architectures.
Switch 32-bit ARM UEFI platforms over to the existing EFI-stub aware
loader initially developed for arm64.
This *WILL* stop non-efistub Linux kernels from booting on arm-efi.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In preparation for using the linux loader for 32-bit and 64-bit platforms,
rename grub_arm64*/GRUB_ARM64* to grub_armxx*/GRUB_ARMXX*.
Move prototypes for now-common functions to efi/efi.h.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Since ARM platforms do not have a common memory map, add a helper
function that finds the lowest address region with the EFI_MEMORY_WB
attribute set in the UEFI memory map.
Required for the arm64 efi linux loader to restrict the initrd
location to where it will be accessible by the kernel at runtime.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
There are several implementations of this function in the tree.
Add a central version in grub-core/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>
To be able to resuse the prop_entry_size macro, move it to
<grub/fdt.h> and rename it grub_fdt_prop_entry_size.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Rename grub_gpt_part_type to grub_gpt_part_guid and update grub_gpt_partentry
to use this type for both the partition type GUID string and the partition GUID
string entries. This change ensures that the two GUID fields are handled more
consistently and helps to simplify the changes needed to add Linux partition
GUID support.
Signed-off-by: Nicholas Vinson <nvinson234@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When building with GCC 8, there are several errors regarding packed-not-aligned.
./include/grub/gpt_partition.h:79:1: error: alignment 1 of ‘struct grub_gpt_partentry’ is less than 8 [-Werror=packed-not-aligned]
This patch fixes the build error by cleaning up the ambiguity of placing
aligned structure in a packed one. In "struct grub_btrfs_time" and "struct
grub_gpt_part_type", the aligned attribute seems to be superfluous, and also
has to be packed, to ensure the structure is bit-to-bit mapped to the format
laid on disk. I think we could blame to copy and paste error here for the
mistake. In "struct efi_variable", we have to use grub_efi_packed_guid_t, as
the name suggests. :)
Signed-off-by: Michael Chang <mchang@suse.com>
Tested-by: Michael Chang <mchang@suse.com>
Tested-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Split up some of the functionality in grub_machine_get_bootlocation into
grub_ieee1275_get_boot_dev. This will allow for code reuse in a follow on
patch.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Return the 64bit number of blocks of storage associated with the device or
instance. Where a "block" is a unit of storage consisting of the number of
bytes returned by the package's "block-size" method. If the size cannot be
determined, or if the number of blocks exceeds the range return -1.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Return the number of blocks of storage associated with the device or
instance. Where a "block" is a unit of storage consisting of the number
of bytes returned by the package's "block-size" method. If the size cannot
be determined, the #blocks method returns the maximum unsigned integer
(which, because of Open Firmware's assumption of two's complement arithmetic,
is equivalent to the signed number -1). If the number of blocks exceeds
the range of an unsigned number, return 0 to alert the caller to try
the #blocks64 command.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
IEEE Std 1275-1994 Standard for Boot (Initialization Configuration)
Firmware: Core Requirements and Practices
3.8.3 deblocker support package
Any package that uses the "deblocker" support package must define
the following method, which the deblocker uses as a low-level
interface to the device
block-size ( -- block-len ) Return "granularity" for accesses to this
device.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.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>
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:
set-address ( unit# target# -- )
Sets the SCSI target number (0x0..0xf) and unit number (0..7) to which
subsequent commands apply.
This function is for devices with #address-cells == 2
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Convert physical address to text unit-string.
Convert phys.lo ... phys-high, the numerical representation, to unit-string,
the text string representation of a physical address within the address
space defined by this device node. The number of cells in the list
phys.lo ... phys.hi is determined by the value of the #address-cells property
of this node.
This function is for devices with #address-cells == 4
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
decode-unit ( addr len -- phys.lo ... phys.hi )
Convert text unit-string to physical address.
Convert unit-string, the text string representation, to phys.lo ... phys.hi,
the numerical representation of a physical address within the address space
defined by this device node. The number of cells in the list
phys.lo ... phys.hi is determined by the value of the #address-cells
property of this node.
This function is for devices with #address-cells == 4
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
grub_aout_load() has a grub_file_t parameter, and depending on what order
includes land in, it's sometimes not defined. This patch explicitly adds
file.h to aout.h so that it will always be defined.
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
<grub/machine/loader.h> (for machine arm/efi) and
<grub/machine/kernel.h> (for machine arm/coreboot) will not always
resolve (and will likely not be valid to) if pulled in when building
non-native commands, such as host tools or the "file" command.
So explicitly include them with their expanded pathnames.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Use kernel header struct and magic definition to align (and coexist) with
i386/arm64 ports.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
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>
Replace uses of GRUB_LINUX_MACHINE_HEADER and GRUB_LINUX_CPU_HEADER
with GRUB_<arch>_LINUX_HEADER include guards to prevent issues when
including more than one of them.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The EFI page definitions and macros are generic and should not be confined
to arm64 headers - so move to efi/memory.h.
Also add EFI_PAGE_SIZE macro.
Update loader sources to reflect new header location.
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>
Code is currently ignoring errors from efibootmgr, giving users
clearly bogus output like:
Setting up grub-efi-amd64 (2.02~beta3-4) ...
Installing for x86_64-efi platform.
Could not delete variable: No space left on device
Could not prepare Boot variable: No space left on device
Installation finished. No error reported.
and then potentially unbootable systems. If efibootmgr fails, grub-install
should know that and report it!
We've been using similar patch in Debian now for some time, with no ill effects.
Signed-off-by: Steve McIntyre <93sam@debian.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When we exit grub, we don't free all the memory that we allocated earlier
for our heap region. This can cause problems with setups where you try
to descend the boot order using "exit" entries, such as PXE -> HD boot
scenarios.
Signed-off-by: Alexander Graf <agraf@suse.de>
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>
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
Add a generic GRUB_PE32_MAGIC definition for the PE 'MZ' tag and delete
the existing one in arm64/linux.h.
Update arm64 Linux loader to use this new definition.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
There is nothing ARM64 (or even ARM) specific about the efi fdt helper
library, which is used for locating or overriding a firmware-provided
devicetree in a UEFI system - so move it to loader/efi for reuse.
Move the fdtload.h include file to grub/efi and update path to
efi/fdtload.h in source code referring to it.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
grub_efi_allocate_pages Essentially does 2 unrelated things:
* Allocate at fixed address.
* Allocate at any address.
To switch between 2 different functions it uses address == 0 as magic
value which is wrong as 0 is a perfectly valid fixed adress to allocate at.
Expose a new function, grub_efi_allocate_pages_real(), making it possible
to specify allocation type and memory type as supported by the UEFI
AllocatePages boot service.
Make grub_efi_allocate_pages() a consumer of the new function,
maintaining its old functionality.
Also delete some left-around #if 1/#else blocks in the affected
functions.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Jesús Diéguez Fernández