Alec Brown [Thu, 27 Oct 2022 00:16:44 +0000 (20:16 -0400)]
video/readers: Add artificial limit to image dimensions
In grub-core/video/readers/jpeg.c, the height and width of a JPEG image don't
have an upper limit for how big the JPEG image can be. In Coverity, this is
getting flagged as an untrusted loop bound. This issue can also seen in PNG and
TGA format images as well but Coverity isn't flagging it. To prevent this, the
constant IMAGE_HW_MAX_PX is being added to include/grub/bitmap.h, which has
a value of 16384, to act as an artificial limit and restrict the height and
width of images. This value was picked as it is double the current max
resolution size, which is 8K.
Fixes: CID 292450 Signed-off-by: Alec Brown <alec.r.brown@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Steve McIntyre [Sun, 18 Sep 2022 12:50:26 +0000 (12:50 +0000)]
Explicitly unset SOURCE_DATE_EPOCH before running fs tests.
In some filesystem utils like mksquashfs, it will silently change
behaviour and cause timestamps to unexpectedly change. Reproducible
builds are good and useful for shipped artifacts, but this causes
build-time tests to fail.
Darren Kenny [Thu, 7 Apr 2022 15:18:12 +0000 (15:18 +0000)]
fs/btrfs: Fix more fuzz issues related to chunks
The corpus was generating issues in grub_btrfs_read_logical() when
attempting to iterate over stripe entries in the superblock's
bootmapping.
In most cases the reason for the failure was that the number of stripes
in chunk->nstripes exceeded the possible space statically allocated in
superblock bootmapping space. Each stripe entry in the bootmapping block
consists of a grub_btrfs_key followed by a grub_btrfs_chunk_stripe.
Another issue that came up was that while calculating the chunk size,
in an earlier piece of code in that function, depending on the data
provided in the btrfs file system, it would end up calculating a size
that was too small to contain even 1 grub_btrfs_chunk_item, which is
obviously invalid too.
Signed-off-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Darren Kenny [Tue, 29 Mar 2022 15:52:46 +0000 (15:52 +0000)]
fs/btrfs: Fix more ASAN and SEGV issues found with fuzzing
The fuzzer is generating btrfs file systems that have chunks with
invalid combinations of stripes and substripes for the given RAID
configurations.
After examining the Linux kernel fs/btrfs/tree-checker.c code, it
appears that sub-stripes should only be applied to RAID10, and in that
case there should only ever be 2 of them.
Similarly, RAID single should only have 1 stripe, and RAID1/1C3/1C4
should have 2. 3 or 4 stripes respectively, which is what redundancy
corresponds.
Some of the chunks ended up with a size of 0, which grub_malloc() still
returned memory for and in turn generated ASAN errors later when
accessed.
While it would be possible to specifically limit the number of stripes,
a more correct test was on the combination of the chunk item, and the
number of stripes by the size of the chunk stripe structure in
comparison to the size of the chunk itself.
Signed-off-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Darren Kenny [Tue, 29 Mar 2022 10:49:56 +0000 (10:49 +0000)]
fs/btrfs: Fix several fuzz issues with invalid dir item sizing
According to the btrfs code in Linux, the structure of a directory item
leaf should be of the form:
|struct btrfs_dir_item|name|data|
in GRUB the name len and data len are in the grub_btrfs_dir_item
structure's n and m fields respectively.
The combined size of the structure, name and data should be less than
the allocated memory, a difference to the Linux kernel's struct
btrfs_dir_item is that the grub_btrfs_dir_item has an extra field for
where the name is stored, so we adjust for that too.
Signed-off-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A corrupt f2fs file system might specify a name length which is greater
than the maximum name length supported by the GRUB f2fs driver.
We will allocate enough memory to store the overly long name, but there
are only F2FS_NAME_LEN bytes in the source, so we would read past the end
of the source.
While checking directory entries, do not copy a file name with an invalid
length.
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com> Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A corrupt f2fs filesystem could have a block offset or a bitmap
offset that would cause us to read beyond the bounds of the nat
bitmap.
Introduce the nat_bitmap_size member in grub_f2fs_data which holds
the size of nat bitmap.
Set the size when loading the nat bitmap in nat_bitmap_ptr(), and
catch when an invalid offset would create a pointer past the end of
the allocated space.
Check against the bitmap size in grub_f2fs_test_bit() test bit to avoid
reading past the end of the nat bitmap.
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com> Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Tue, 8 Mar 2022 08:04:40 +0000 (19:04 +1100)]
net/http: Error out on headers with LF without CR
In a similar vein to the previous patch, parse_line() would write
a NUL byte past the end of the buffer if there was an HTTP header
with a LF rather than a CRLF.
RFC-2616 says:
Many HTTP/1.1 header field values consist of words separated by LWS
or special characters. These special characters MUST be in a quoted
string to be used within a parameter value (as defined in section 3.6).
We don't support quoted sections or continuation lines, etc.
If we see an LF that's not part of a CRLF, bail out.
Fixes: CVE-2022-28734 Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Tue, 8 Mar 2022 07:17:03 +0000 (18:17 +1100)]
net/http: Fix OOB write for split http headers
GRUB has special code for handling an http header that is split
across two packets.
The code tracks the end of line by looking for a "\n" byte. The
code for split headers has always advanced the pointer just past the
end of the line, whereas the code that handles unsplit headers does
not advance the pointer. This extra advance causes the length to be
one greater, which breaks an assumption in parse_line(), leading to
it writing a NUL byte one byte past the end of the buffer where we
reconstruct the line from the two packets.
It's conceivable that an attacker controlled set of packets could
cause this to zero out the first byte of the "next" pointer of the
grub_mm_region structure following the current_line buffer.
Do not advance the pointer in the split header case.
Fixes: CVE-2022-28734 Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Tue, 1 Mar 2022 12:14:15 +0000 (23:14 +1100)]
net/http: Do not tear down socket if it's already been torn down
It's possible for data->sock to get torn down in tcp error handling.
If we unconditionally tear it down again we will end up doing writes
to an offset of the NULL pointer when we go to tear it down again.
Detect if it has been torn down and don't do it again.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Tue, 18 Jan 2022 03:29:20 +0000 (14:29 +1100)]
net/tftp: Avoid a trivial UAF
Under tftp errors, we print a tftp error message from the tftp header.
However, the tftph pointer is a pointer inside nb, the netbuff. Previously,
we were freeing the nb and then dereferencing it. Don't do that, use it
and then free it later.
This isn't really _bad_ per se, especially as we're single-threaded, but
it trips up fuzzers.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Sun, 19 Sep 2021 15:12:24 +0000 (01:12 +1000)]
net/tftp: Prevent a UAF and double-free from a failed seek
A malicious tftp server can cause UAFs and a double free.
An attempt to read from a network file is handled by grub_net_fs_read(). If
the read is at an offset other than the current offset, grub_net_seek_real()
is invoked.
In grub_net_seek_real(), if a backwards seek cannot be satisfied from the
currently received packets, and the underlying transport does not provide
a seek method, then grub_net_seek_real() will close and reopen the network
protocol layer.
For tftp, the ->close() call goes to tftp_close() and frees the tftp_data_t
file->data. The file->data pointer is not nulled out after the free.
If the ->open() call fails, the file->data will not be reallocated and will
continue point to a freed memory block. This could happen from a server
refusing to send the requisite ack to the new tftp request, for example.
The seek and the read will then fail, but the grub_file continues to exist:
the failed seek does not necessarily cause the entire file to be thrown
away (e.g. where the file is checked to see if it is gzipped/lzio/xz/etc.,
a read failure is interpreted as a decompressor passing on the file, not as
an invalidation of the entire grub_file_t structure).
This means subsequent attempts to read or seek the file will use the old
file->data after free. Eventually, the file will be close()d again and
file->data will be freed again.
Mark a net_fs file that doesn't reopen as broken. Do not permit read() or
close() on a broken file (seek is not exposed directly to the file API -
it is only called as part of read, so this blocks seeks as well).
As an additional defence, null out the ->data pointer if tftp_open() fails.
That would have lead to a simple null pointer dereference rather than
a mess of UAFs.
This may affect other protocols, I haven't checked.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Mon, 20 Dec 2021 10:55:43 +0000 (21:55 +1100)]
net/dns: Don't read past the end of the string we're checking against
I don't really understand what's going on here but fuzzing found
a bug where we read past the end of check_with. That's a C string,
so use grub_strlen() to make sure we don't overread it.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Wed, 15 Sep 2021 15:29:54 +0000 (01:29 +1000)]
net/dns: Fix double-free addresses on corrupt DNS response
grub_net_dns_lookup() takes as inputs a pointer to an array of addresses
("addresses") for the given name, and pointer to a number of addresses
("naddresses"). grub_net_dns_lookup() is responsible for allocating
"addresses", and the caller is responsible for freeing it if
"naddresses" > 0.
The DNS recv_hook will sometimes set and free the addresses array,
for example if the packet is too short:
if (ptr + 10 >= nb->tail)
{
if (!*data->naddresses)
grub_free (*data->addresses);
grub_netbuff_free (nb);
return GRUB_ERR_NONE;
}
Later on the nslookup command code unconditionally frees the "addresses"
array. Normally this is fine: the array is either populated with valid
data or is NULL. But in these sorts of error cases it is neither NULL
nor valid and we get a double-free.
Only free "addresses" if "naddresses" > 0.
It looks like the other use of grub_net_dns_lookup() is not affected.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Tue, 13 Jul 2021 03:24:38 +0000 (13:24 +1000)]
normal/charset: Fix array out-of-bounds formatting unicode for display
In some cases attempting to display arbitrary binary strings leads
to ASAN splats reading the widthspec array out of bounds.
Check the index. If it would be out of bounds, return a width of 1.
I don't know if that's strictly correct, but we're not really expecting
great display of arbitrary binary data, and it's certainly not worse than
an OOB read.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Wed, 7 Jul 2021 05:38:19 +0000 (15:38 +1000)]
video/readers/jpeg: Block int underflow -> wild pointer write
Certain 1 px wide images caused a wild pointer write in
grub_jpeg_ycrcb_to_rgb(). This was caused because in grub_jpeg_decode_data(),
we have the following loop:
On a 64-bit platform, if that turns out to be negative, it will underflow,
be interpreted as unsigned 64-bit, then be added to the 64-bit pointer, so
we see data->bitmap_ptr jump, e.g.:
0x6180_0000_0480 to
0x6181_0000_0498
^
~--- carry has occurred and this pointer is now far away from
any object.
On a 32-bit platform, it will decrement the pointer, creating a pointer
that won't crash but will overwrite random data.
Catch the underflow and error out.
Fixes: CVE-2021-3697 Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Mon, 28 Jun 2021 04:25:17 +0000 (14:25 +1000)]
video/readers/jpeg: Refuse to handle multiple start of streams
An invalid file could contain multiple start of stream blocks, which
would cause us to reallocate and leak our bitmap. Refuse to handle
multiple start of streams.
Additionally, fix a grub_error() call formatting.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In fuzzing we observed crashes where a code would attempt to be inserted
into a huffman table before the start, leading to a set of heap OOB reads
and writes as table entries with negative indices were shifted around and
the new code written in.
Catch the case where we would underflow the array and bail.
Fixes: CVE-2021-3696 Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Tue, 6 Jul 2021 08:51:35 +0000 (18:51 +1000)]
video/readers/png: Drop greyscale support to fix heap out-of-bounds write
A 16-bit greyscale PNG without alpha is processed in the following loop:
for (i = 0; i < (data->image_width * data->image_height);
i++, d1 += 4, d2 += 2)
{
d1[R3] = d2[1];
d1[G3] = d2[1];
d1[B3] = d2[1];
}
The increment of d1 is wrong. d1 is incremented by 4 bytes per iteration,
but there are only 3 bytes allocated for storage. This means that image
data will overwrite somewhat-attacker-controlled parts of memory - 3 bytes
out of every 4 following the end of the image.
This has existed since greyscale support was added in 2013 in commit 3ccf16dff98f (grub-core/video/readers/png.c: Support grayscale).
Saving starfield.png as a 16-bit greyscale image without alpha in the gimp
and attempting to load it causes grub-emu to crash - I don't think this code
has ever worked.
Delete all PNG greyscale support.
Fixes: CVE-2021-3695 Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
kern/efi/sb: Reject non-kernel files in the shim_lock verifier
We must not allow other verifiers to pass things like the GRUB modules.
Instead of maintaining a blocklist, maintain an allowlist of things
that we do not care about.
This allowlist really should be made reusable, and shared by the
lockdown verifier, but this is the minimal patch addressing
security concerns where the TPM verifier was able to mark modules
as verified (or the OpenPGP verifier for that matter), when it
should not do so on shim-powered secure boot systems.
Fixes: CVE-2022-28735 Signed-off-by: Julian Andres Klode <julian.klode@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Chris Coulson [Tue, 5 Apr 2022 10:48:58 +0000 (11:48 +0100)]
loader/efi/chainloader: Use grub_loader_set_ex()
This ports the EFI chainloader to use grub_loader_set_ex() in order to fix
a use-after-free bug that occurs when grub_cmd_chainloader() is executed
more than once before a boot attempt is performed.
Fixes: CVE-2022-28736 Signed-off-by: Chris Coulson <chris.coulson@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Chris Coulson [Fri, 29 Apr 2022 20:16:02 +0000 (21:16 +0100)]
commands/boot: Add API to pass context to loader
Loaders rely on global variables for saving context which is consumed
in the boot hook and freed in the unload hook. In the case where a loader
command is executed twice, calling grub_loader_set a second time executes
the unload hook, but in some cases this runs when the loader's global
context has already been updated, resulting in the updated context being
freed and potential use-after-free bugs when the boot hook is subsequently
called.
This adds a new API (grub_loader_set_ex) which allows a loader to specify
context that is passed to its boot and unload hooks. This is an alternative
to requiring that loaders call grub_loader_unset before mutating their
global context.
Chris Coulson [Tue, 5 Apr 2022 09:02:04 +0000 (10:02 +0100)]
loader/efi/chainloader: Simplify the loader state
The chainloader command retains the source buffer and device path passed
to LoadImage(), requiring the unload hook passed to grub_loader_set() to
free them. It isn't required to retain this state though - they aren't
required by StartImage() or anything else in the boot hook, so clean them
up before grub_cmd_chainloader() finishes.
Signed-off-by: Chris Coulson <chris.coulson@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Colin Watson [Sun, 28 Nov 2021 23:42:30 +0000 (23:42 +0000)]
minilzo: Update to minilzo-2.10
minilzo fails to build on a number of Debian release architectures
(armel, mips64el, mipsel, ppc64el) with errors such as:
../../grub-core/lib/minilzo/minilzo.c: In function 'lzo_memops_get_le16':
../../grub-core/lib/minilzo/minilzo.c:3479:11: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
3479 | * (lzo_memops_TU2p) (lzo_memops_TU0p) (dd) = * (const lzo_memops_TU2p) (const lzo_memops_TU0p) (ss); \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../grub-core/lib/minilzo/minilzo.c:3530:5: note: in expansion of macro 'LZO_MEMOPS_COPY2'
3530 | LZO_MEMOPS_COPY2(&v, ss);
| ^~~~~~~~~~~~~~~~
The latest upstream version is 2.10, so updating to it seems like a good
idea on general principles, and it fixes builds on all the above
architectures.
The update procedure documented in the GRUB Developers Manual worked; I
just updated the version numbers to make it clear that it's been
executed recently.
Signed-off-by: Colin Watson <cjwatson@debian.org>
Forwarded: https://lists.gnu.org/archive/html/grub-devel/2021-11/msg00095.html
Last-Update: 2021-11-29
Marius Bakke [Sun, 13 Jun 2021 13:11:51 +0000 (15:11 +0200)]
tests/ahci: Change "ide-drive" deprecated QEMU device name to "ide-hd"
The "ide-drive" device was removed in QEMU 6.0. The "ide-hd" has been
available for more than 10 years now in QEMU. Thus there shouldn't be
any need for backwards compatible names.
Signed-off-by: Marius Bakke <marius@gnu.org> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=aaea244a6ddd1e35aed60a5c7a08ddc41f51805b
Last-Update: 2021-09-24
Erwan Velu [Wed, 25 Aug 2021 13:31:52 +0000 (15:31 +0200)]
fs/xfs: Fix unreadable filesystem with v4 superblock
The commit 8b1e5d193 (fs/xfs: Add bigtime incompat feature support)
introduced the bigtime support by adding some features in v3 inodes.
This change extended grub_xfs_inode struct by 76 bytes but also changed
the computation of XFS_V2_INODE_SIZE and XFS_V3_INODE_SIZE. Prior this
commit, XFS_V2_INODE_SIZE was 100 bytes. After the commit it's 84 bytes
XFS_V2_INODE_SIZE becomes 16 bytes too small.
As a result, the data structures aren't properly aligned and the GRUB
generates "attempt to read or write outside of partition" errors when
trying to read the XFS filesystem:
GNU GRUB version 2.11
....
grub> set debug=efi,gpt,xfs
grub> insmod part_gpt
grub> ls (hd0,gpt1)/
partmap/gpt.c:93: Read a valid GPT header
partmap/gpt.c:115: GPT entry 0: start=4096, length=1953125
fs/xfs.c:931: Reading sb
fs/xfs.c:270: Validating superblock
fs/xfs.c:295: XFS v4 superblock detected
fs/xfs.c:962: Reading root ino 128
fs/xfs.c:515: Reading inode (128) - 64, 0
fs/xfs.c:515: Reading inode (739521961424144223) - 344365866970255880, 3840
error: attempt to read or write outside of partition.
This commit change the XFS_V2_INODE_SIZE computation by subtracting 76
bytes instead of 92 bytes from the actual size of grub_xfs_inode struct.
This 76 bytes value comes from added members:
20 grub_uint8_t unused5
1 grub_uint64_t flags2
48 grub_uint8_t unused6
This patch explicitly splits the v2 and v3 parts of the structure.
The unused4 is still ending of the v2 structures and the v3 starts
at unused5. Thanks to this we will avoid future corruptions of v2
or v3 inodes.
The XFS_V2_INODE_SIZE is returning to its expected size and the
filesystem is back to a readable state:
util/mkimage: Some fixes to PE binaries section size calculation
Commit f60ba9e5945 (util/mkimage: Refactor section setup to use a helper)
added a helper function to setup PE sections, but it caused regressions
in some arches where the natural alignment lead to wrong section sizes.
This patch fixes a few things that were caused the section sizes to be
calculated wrongly. These fixes are:
* Only align the virtual memory addresses but not the raw data offsets.
* Use aligned sizes for virtual memory sizes but not for raw data sizes.
* Always align the sizes to set the virtual memory sizes.
These seems to not cause problems for x64 and aa64 EFI platforms but was
a problem for ia64. Because the size of the ".data" and "mods" sections
were wrong and didn't have the correct content. Which lead to GRUB not
being able to load any built-in module.
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Bug-Debian: https://bugs.debian.org/987103
Michael Chang [Thu, 18 Mar 2021 11:30:26 +0000 (19:30 +0800)]
i386-pc: build verifiers API as module
Given no core functions on i386-pc would require verifiers to work and
the only consumer of the verifier API is the pgp module, it looks good
to me that we can move the verifiers out of the kernel image and let
moddep.lst to auto-load it when pgp is loaded on i386-pc platform.
This helps to reduce the size of core image and thus can relax the
tension of exploding on some i386-pc system with very short MBR gap
size. See also a very comprehensive summary from Colin [1] about the
details.
V2:
Drop COND_NOT_i386_pc and use !COND_i386_pc.
Add comment in kern/verifiers.c to help understanding what's going on
without digging into the commit history.
Reported-by: Colin Watson <cjwatson@debian.org> Reviewed-by: Colin Watson <cjwatson@debian.org> Signed-off-by: Michael Chang <mchang@suse.com>
Origin: other, https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00251.html
Bug-Debian: https://bugs.debian.org/984488
Bug-Debian: https://bugs.debian.org/985374
Last-Update: 2021-09-24
Colin Watson [Mon, 11 Mar 2019 11:17:43 +0000 (11:17 +0000)]
Minimise writes to EFI variable storage
Some UEFI firmware is easily provoked into running out of space in its
variable storage. This is usually due to certain kernel drivers (e.g.
pstore), but regardless of the cause it can cause grub-install to fail
because it currently asks efibootmgr to delete and re-add entries, and
the deletion often doesn't result in an immediate garbage collection.
Writing variables frequently also increases wear on the NVRAM which may
have limited write cycles. For these reasons, it's desirable to find a
way to minimise writes while still allowing grub-install to ensure that
a suitable boot entry exists.
Unfortunately, efibootmgr doesn't offer an interface that would let
grub-install do this. It doesn't in general make very much effort to
minimise writes; it doesn't allow modifying an existing Boot* variable
entry, except in certain limited ways; and current versions don't have a
way to export the expected variable data so that grub-install can
compare it to the current data. While it would be possible (and perhaps
desirable?) to add at least some of this to efibootmgr, that would still
leave the problem that there isn't a good upstreamable way for
grub-install to guarantee that it has a new enough version of
efibootmgr. In any case, it's cumbersome and slow for grub-install to
have to fork efibootmgr to get things done.
Fortunately, a few years ago Peter Jones helpfully factored out a
substantial part of efibootmgr to the efivar and efiboot libraries, and
so it's now possible to have grub-install use those directly. We still
have to use some code from efibootmgr, but much less than would
previously have been necessary.
grub-install now reuses existing boot entries where possible, and avoids
writing to variables when the new contents are the same as the old
contents. In the common upgrade case where nothing needs to change, it
no longer writes to NVRAM at all. It's also now slightly faster, since
using libefivar is faster than forking efibootmgr.
Fixes Debian bug #891434.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Bug-Debian: https://bugs.debian.org/891434
Forwarded: https://lists.gnu.org/archive/html/grub-devel/2019-03/msg00119.html
Last-Update: 2019-03-23
Fix setup on Secure Boot systems where cryptodisk is in use
On full-encrypted systems, including /boot, the current code omits
cryptodisk commands needed to open the drives if Secure Boot is enabled.
This prevents grub2 from reading any further configuration residing on
the encrypted disk.
This patch fixes this issue by adding the needed "cryptomount" commands in
the load.cfg file that is then copied in the EFI partition.
Jeroen Dekkers [Sat, 12 Jan 2019 20:02:18 +0000 (21:02 +0100)]
at_keyboard: initialize keyboard in module init if keyboard is ready
The change in 0c62a5b2 caused at_keyboard to fail on some
machines. Immediately initializing the keyboard in the module init if
the keyboard is ready makes the problem go away.
Luca Boccassi [Tue, 15 May 2018 10:36:46 +0000 (11:36 +0100)]
Do not overwrite sentinel byte in boot_params, breaks lockdown
grub currently copies the entire boot_params, which includes setting
sentinel byte to 0xff, which triggers sanitize_boot_params in the kernel
which in turn clears various boot_params variables, including the
indication that the bootloader chain is verified and thus the kernel
disables lockdown mode. According to the information on the Fedora bug
tracker, only the information from byte 0x1f1 is necessary, so start
copying from there instead.
Author: Luca Boccassi <bluca@debian.org>
Bug-Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1418360
Forwarded: no
Michael Chang [Thu, 27 Oct 2016 21:43:21 +0000 (17:43 -0400)]
efinet: Setting DNS server from UEFI protocol
In the URI device path node, any name rahter than address can be used for
looking up the resources so that DNS service become needed to get answer of the
name's address. Unfortunately the DNS is not defined in any of the device path
nodes so that we use the EFI_IP4_CONFIG2_PROTOCOL and EFI_IP6_CONFIG_PROTOCOL
to obtain it.
These two protcols are defined the sections of UEFI specification.
include/grub/efi/api.h:
Add new structure and protocol UUID of EFI_IP4_CONFIG2_PROTOCOL and
EFI_IP6_CONFIG_PROTOCOL.
grub-core/net/drivers/efi/efinet.c:
Use the EFI_IP4_CONFIG2_PROTOCOL and EFI_IP6_CONFIG_PROTOCOL to obtain the list
of DNS server address for IPv4 and IPv6 respectively. The address of DNS
servers is structured into DHCPACK packet and feed into the same DHCP packet
processing functions to ensure the network interface is setting up the same way
it used to be.
Signed-off-by: Michael Chang <mchang@suse.com> Signed-off-by: Ken Lin <ken.lin@hpe.com>
Last-Update: 2021-09-24
Michael Chang [Thu, 27 Oct 2016 21:43:05 +0000 (17:43 -0400)]
efinet: Setting network from UEFI device path
The PXE Base Code protocol used to obtain cached PXE DHCPACK packet is no
longer provided for HTTP Boot. Instead, we have to get the HTTP boot
information from the device path nodes defined in following UEFI Specification
sections.
include/grub/efi/api.h:
Add new structure of Uniform Resource Identifiers (URI) Device Path
grub-core/net/drivers/efi/efinet.c:
Check if PXE Base Code is available, if not it will try to obtain the netboot
information from the device path where the image booted from. The DHCPACK
packet is recoverd from the information in device patch and feed into the same
DHCP packet processing functions to ensure the network interface is setting up
the same way it used to be.
Signed-off-by: Michael Chang <mchang@suse.com> Signed-off-by: Ken Lin <ken.lin@hpe.com>
Patch-Name: efinet-set-network-from-uefi-devpath.patch
Michael Chang [Thu, 27 Oct 2016 21:42:19 +0000 (17:42 -0400)]
bootp: Add processing DHCPACK packet from HTTP Boot
The vendor class identifier with the string "HTTPClient" is used to denote the
packet as responding to HTTP boot request. In DHCP4 config, the filename for
HTTP boot is the URL of the boot file while for PXE boot it is the path to the
boot file. As a consequence, the next-server becomes obseleted because the HTTP
URL already contains the server address for the boot file. For DHCP6 config,
there's no difference definition in existing config as dhcp6.bootfile-url can
be used to specify URL for both HTTP and PXE boot file.
This patch adds processing for "HTTPClient" vendor class identifier in DHCPACK
packet by treating it as HTTP format, not as the PXE format.
Signed-off-by: Michael Chang <mchang@suse.com> Signed-off-by: Ken Lin <ken.lin@hpe.com>
Last-Update: 2021-09-24
Michael Chang [Thu, 27 Oct 2016 21:41:21 +0000 (17:41 -0400)]
efinet: UEFI IPv6 PXE support
When grub2 image is booted from UEFI IPv6 PXE, the DHCPv6 Reply packet is
cached in firmware buffer which can be obtained by PXE Base Code protocol. The
network interface can be setup through the parameters in that obtained packet.
Signed-off-by: Michael Chang <mchang@suse.com> Signed-off-by: Ken Lin <ken.lin@hpe.com>
Patch-Name: efinet-uefi-ipv6-pxe-support.patch
Aaron Miller [Thu, 27 Oct 2016 21:39:49 +0000 (17:39 -0400)]
net: read bracketed ipv6 addrs and port numbers
Allow specifying port numbers for http and tftp paths, and allow ipv6 addresses
to be recognized with brackets around them, which is required to specify a port
number
Chad MILLER [Thu, 27 Oct 2016 21:15:07 +0000 (17:15 -0400)]
Tell zpool to emit full device names
zfs-initramfs currently provides extraneous, undesired symlinks to
devices directly underneath /dev/ to satisfy zpool's historical output
of unqualified device names. By including this environment variable to
signal our intent to zpool, zfs-linux packages can drop the symlink
behavior when updating to its upstream or backported output behavior.
Steve McIntyre [Wed, 3 Dec 2014 01:25:12 +0000 (01:25 +0000)]
Add support for forcing EFI installation to the removable media path
Add an extra option to grub-install "--force-extra-removable". On EFI
platforms, this will cause an extra copy of the grub-efi image to be
written to the appropriate removable media patch
/boot/efi/EFI/BOOT/BOOT$ARCH.EFI as well. This will help with broken
UEFI implementations where the firmware does not work when configured
with new boot paths.
Signed-off-by: Steve McIntyre <93sam@debian.org>
Bug-Debian: https://bugs.debian.org/767037 https://bugs.debian.org/773092
Forwarded: Not yet
Last-Update: 2021-09-24
Ian Campbell [Sun, 30 Nov 2014 12:12:52 +0000 (12:12 +0000)]
Arrange to insmod xzio and lzopio when booting a kernel as a Xen guest
This is needed in case the Linux kernel is compiled with CONFIG_KERNEL_XZ or
CONFIG_KERNEL_LZO rather than CONFIG_KERNEL_GZ (gzio is already loaded by
grub.cfg today).
Signed-off-by: Ian Campbell <ijc@debian.org>
Bug-Debian: https://bugs.debian.org/755256
Forwarded: http://lists.gnu.org/archive/html/grub-devel/2014-11/msg00091.html
Last-Update: 2014-11-30
Ian Campbell [Sat, 6 Sep 2014 11:20:12 +0000 (12:20 +0100)]
grub-install: Install PV Xen binaries into the upstream specified path
Upstream have defined a specification for where guests ought to place their
xenpv grub binaries in order to facilitate chainloading from a stage 1 grub
loaded from dom0.
VSX bit is enabled by default for Power7 and Power8 CPU models,
so we need to disable them in order to avoid instruction exceptions.
Kernel will activate it when necessary.
Colin Watson [Tue, 28 Jan 2014 14:40:02 +0000 (14:40 +0000)]
Port yaboot logic for various powerpc machine types
Some powerpc machines require not updating the NVRAM. This can be handled
by existing grub-install command-line options, but it's friendlier to detect
this automatically.
On chrp_ibm machines, use the nvram utility rather than nvsetenv. (This
is possibly suitable for other machines too, but that needs to be
verified.)
projects / grub2.git / log