get_card_packet() from ofnet.c allocates a netbuff based on the device's MTU:
nb = grub_netbuff_alloc (dev->mtu + 64 + 2);
In the case when the MTU is large, and the received packet is
relatively small, this leads to allocation of significantly more memory,
than it's required. An example could be transmission of TFTP packets
with 0x400 blksize via a network card with 0x10000 MTU.
This patch implements a per-card receive buffer in a way similar to efinet.c,
and makes get_card_packet() allocate a netbuff of the received data size.
Signed-off-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In the current code search_net_devices() uses the "alloc-mem" command
from the IEEE1275 User Interface for allocation of the transmit buffer
for the case when GRUB_IEEE1275_FLAG_VIRT_TO_REAL_BROKEN is set.
I don't have hardware where this flag is set to verify if this
workaround is still needed. However, further changes to ofnet will
require to execute this workaround one more time. Therefore, to
avoid possible duplication of code I'm moving this piece of
code into a function.
Signed-off-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
We only support FDT files with EFI on arm and arm64 systems, not
on x86. So move the helper that finds a prepopulated FDT UUID
into its own file and only build it for architectures where it
also gets called.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Network boot autoconfiguration sets default server to next server IP
(siaddr) from BOOTP/DHCP reply, but manual configuration using net_bootp
exports only server name. Unfortunately semantic of server name is not
clearly defined. BOOTP RFC 951 defines it only for client request, and
DHCP RFC 1541 only mentions it, without any implied usage. It looks like
this field is mostly empty in server replies.
Export next server IP as net_<interface>_next_server variable. This allows
grub configuration script to set $root/$prefix based on information obtained
by net_bootp.
Reported and tested by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Cc: nikunj@linux.vnet.ibm.com
v2: change variable name to net_<interface>_next_server as discussed on the list
If EFI is nice enough to pass us an FDT using configuration tables on 32bit
ARM, we should really try and make use of it.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Searching for a device tree that EFI passes to us via configuration tables
is nothing architecture specific. Move it into generic code.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
grub_util_get_dm_abstraction() does a string comparison of insufficient
length. When using a UUID such as "CRYPT-PLAIN-sda6_crypt", the function
returns GRUB_DEV_ABSTRACTION_LUKS.
This results in the error:
./grub-probe: error: disk `cryptouuid/sda6_crypt' not found.
This appears to be a copy/paste error introduced in:
a10e7a5a89
The bug was (apparently) latent until revealed by:
3bca85b418
Signed-off-by: Corey Hickey <bugfood-c@fatooh.org>
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>
Get actual version of include/xen/xen.h from the Xen repository in
order to be able to use constants defined there.
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>
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>
limit_time underflows when current time is less than 90000ms.
This causes packet fragments received during this time, i.e.,
till 90000ms pass since timer init, to be rejected.
Hence, set it to 0 if its less than 90000.
Signed-off-by: Sakar Arora <Sakar.Arora@nxp.com>
LLVM 3.9 now emits short form of jump instructions, but it is still using
32 bit addresses for some movl instructions. Fortunately it was caught early:
clang ... boot/i386/pc/boot.S
clang -cc1as: fatal error: error in backend: invalid .org offset '440' (at offset '441')
Add additional check to catch it during configure run and force -no-integrated-as.
Closes: 49200
More details in
https://lists.gnu.org/archive/html/grub-devel/2015-02/msg00099.htmlhttps://llvm.org/bugs/show_bug.cgi?id=22662
We may get more than one response before exiting out of loop in
grub_net_dns_lookup, but buffer was allocated for the first response only,
so storing answers from subsequent replies wrote past allocated size.
We never really use more than the very first address during lookup so there
is little point in collecting all of them. Just quit early if we already have
some reply.
Code needs serious redesign to actually collect multiple answers
and select the best fit according to requested type (IPv4 or IPv6).
Reported and tested by Michael Chang <mchang@suse.com>
XFS V5 stores UUID in metadata and compares them with superblock UUID.
To allow changing of user-visible UUID it stores original value in new
superblock field (meta_uuid) and sets incompatible flag to indicate that
new field must be used to verify metadata. Our driver currently does not
check metadata UUID so simply accept such filesystem.
Reported-By: Marcos Mello <marcosfrm@outlook.com>
Reviewd by Jan Kara <jack@suse.cz>
If we open new connection, we need to reset stall indication, otherwise
nothing will ever be polled (low level code rely on this field being
zero when establishing connection).
Depending on the OS/libc, device macros are defined in different
headers. This change ensures we include the right one.
sys/types.h - BSD
sys/mkdev.h - Sun
sys/sysmacros.h - glibc (Linux)
glibc currently pulls sys/sysmacros.h into sys/types.h, but this may
change in a future release.
https://sourceware.org/ml/libc-alpha/2015-11/msg00253.html
At least the apache sever is very unhappy with that extra null line and will
take more than ten seconds in responding to each range request, which slows
down a lot the entire http file transfer process or even time out.
OpenBSD 5.9 apparently defaults to -fpie. We use -fno-PIE when appropriate
already, but that is not enough - it does not turn off -fpie.
Actually check for -fPIE is not precise enough. __PIE__ is set for both
-fpie and -fPIE but with different values. As far as I can tell, both
options were introduced at the same time, so both should always be supported.
This fixes compilation on OpenBSD 5.9 which otherwise created insanely big
lzma_decompress.img.
Reported, suggested and tested by: Jiri B <jirib@devio.us>
Historically this variable hold previous value of filename that
had to be freed if allocated previously. Currently this branch
is entered only if filename was not allocated previously so it
became redundant. It did not cause real problems because grub_free
was not called, but code is confusing and causes compilation error
in some cases.
Grub would notify the user if the new config was invalid, however, it
did not exit properly with exit code 1. Added the proper exit code.
Resolves: rhbz#1252311
