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
Returned from the OpenProtocol operation, the grub_efi_block_io_media
structure contains the io_align field, specifying the minimum alignment
required for buffers used in any data transfers with the device.
Make grub_efidisk_readwrite() allocate a temporary buffer, aligned to
this boundary, if the buffer passed to it does not already meet the
requirements.
Also sanity check the io_align field in grub_efidisk_open() for
power-of-two-ness and bail if invalid.
util/grub-mkimagexx.c is included in a special way into mkimage.c.
Interoperation between defines makes this very tricky. Instead
just have a clean interface and compile util/grub-mkimage*.c separately
from mkimage.c
Map EFI_NO_MEDIA to GRUB_ERR_OUT_OF_RANGE that is ignored by diskfilter. This
actually matches pretty close (we obviously attempt to read outside of media)
and avoids adding more error codes.
This affects only internally initiated scans. If read/write from removable is
explicitly requested, we still return an error and text explanation is more
clear for user than generic error.
Reported and tested by Andreas Loew <Andreas.Loew@gmx.net>
ipv6 routing in grub2 is broken, we cannot talk to anything outside our local
network or anything that doesn't route in our global namespace. This patch
fixes this by doing a couple of things
1) Read the router information off of the router advertisement. If we have a
router lifetime we need to take the source address and create a route from it.
2) Changes the routing stuff slightly to allow you to specify a gateway _and_ an
interface. Since the router advertisements come in on the link local address we
need to associate it with the global address on the card. So when we are
processing the router advertisement, either use the SLAAC interface we create
and add the route to that interface, or loop through the global addresses we
currently have on our interface and associate it with one of those addresses.
We need to have a special case here for the default route so that it gets used,
we do this by setting the masksize to 0 to mean it encompasses all networks.
The routing code will automatically select the best route so if there is a
closer match we will use that.
With this patch I can now talk to ipv6 addresses outside of my local network.
Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
