Re: [PATCH] lvm: allocate metadata buffer from raw contents
On Thu, Oct 03, 2024 at 10:30:15AM GMT, ross.philip...@oracle.com wrote:
> On 10/3/24 12:23 AM, Michael Chang via Grub-devel wrote:
> > Previously, the buffer for LVM metadata parsing was set to twice the
> > size of the metadata area, which caused excessive memory use.
> >
> > This patch changes the allocation to read the actual raw metadata blocks
> > directly from the metadata area. Instead of using twice the entire
> > metadata area size, we now allocate just what’s needed for the raw
> > metadata.
> >
> > This change effectively reduces the buffer size while still working
> > correctly. In my test system on openSUSE, the buffer size for LVM
> > metadata dropped from 2,088,960 bytes to 1,119 bytes, which is a big
>
> Looking at the description here, I am not sure I understand these numbers.
> How did it go from around a 2M buffer to a roughly 1K one? If that is the
> case, they were allocating way more than 2x what was needed.
We can determine the size of the LVM metadata area by running the command:
pvs -o pv_name,pv_mda_size
As a result, grub will allocate 2 * pv_mda_size, and since 1MiB is a
common default for pv_mda_size nowadays (it seems), this results in 2MiB
being allocated.
However, most of the blocks in the metadata area are not useful to grub.
A lot of space gets wasted because it is occupied by a pre-allocated
circular buffer, which is used to track changes over time. To eliminate
this overhead, we can teach grub to use the raw metadata block to locate
the active metadata within the circular buffer. In the end, only 1,119
bytes are actually needed.
We've been using this patch since 2017, and I believe it is quite
stable. The circular buffer wrapping is also tested and covered. To give
some context on why we developed this patch, LVM used to allocate an
absurdly large mda_size on multipath disk setups [1], which caused boot
failures on PowerPC systems [2]. While this LVM issue may have been
fixed by now, I think it's still worth upstreaming this optimization.
[1]
pvs -o pv_mda_size /dev/mapper/36...-part2
PMdaSize
63.94m
[2]
Elapsed time since release of system processors: 190437 mins 52 secs
Welcome to GRUB!
error: out of memory.
error: disk
`lvmid/efy0wc-Jr8x-yDG5-wEeI-k4ls-ql9Z-vKxAq0/UXMrG0-2C0A-1AaG-bzRv-
uSgG-lmK3-SAdAe5' not found.
Entering rescue mode...
Thanks,
Michael
>
> Thanks
> Ross
>
> > improvement.
> >
> > Signed-off-by: Michael Chang
> > ---
> > grub-core/disk/lvm.c | 79
> > 1 file changed, 43 insertions(+), 36 deletions(-)
> >
> > diff --git a/grub-core/disk/lvm.c b/grub-core/disk/lvm.c
> > index 0c32c95f9..ea260b47e 100644
> > --- a/grub-core/disk/lvm.c
> > +++ b/grub-core/disk/lvm.c
> > @@ -140,9 +140,11 @@ grub_lvm_detect (grub_disk_t disk,
> > grub_err_t err;
> > grub_uint64_t mda_offset, mda_size;
> > grub_size_t ptr;
> > + grub_uint64_t mda_raw_offset, mda_raw_size;
> > char buf[GRUB_LVM_LABEL_SIZE];
> > char vg_id[GRUB_LVM_ID_STRLEN+1];
> > char pv_id[GRUB_LVM_ID_STRLEN+1];
> > + char mdah_buf[sizeof (struct grub_lvm_mda_header) + sizeof (struct
> > grub_lvm_raw_locn)];
> > char *metadatabuf, *mda_end, *vgname;
> > const char *p, *q;
> > struct grub_lvm_label_header *lh = (struct grub_lvm_label_header *) buf;
> > @@ -220,21 +222,15 @@ grub_lvm_detect (grub_disk_t disk,
> > dlocn++;
> > mda_offset = grub_le_to_cpu64 (dlocn->offset);
> > - mda_size = grub_le_to_cpu64 (dlocn->size);
> > /* It's possible to have multiple copies of metadata areas, we just use
> > the
> >first one. */
> > -
> > - /* Allocate buffer space for the circular worst-case scenario. */
> > - metadatabuf = grub_calloc (2, mda_size);
> > - if (! metadatabuf)
> > + err = grub_disk_read (disk, 0, mda_offset, sizeof (mdah_buf), mdah_buf);
> > + if (err)
> > goto fail;
> > - err = grub_disk_read (disk, 0, mda_offset, mda_size, metadatabuf);
> > - if (err)
> > -goto fail2;
> > + mdah = (struct grub_lvm_mda_header *) mdah_buf;
> > - mdah = (struct grub_lvm_mda_header *) metadatabuf;
> > if ((grub_strncmp ((char *)mdah->magic, GRUB_LVM_FMTT_MAGIC,
> > sizeof (mdah->magic)))
> > || (grub_le_to_cpu32 (mdah->version) != GRUB_LVM_FMTT_VERSION))
> > @@ -244,42 +240,58 @@ grub_lvm_detect (grub_disk_t disk,
> > #ifdef GRUB_UTIL
> > grub_util_info ("unknown LVM metadata header");
> > #endif
> > - goto fail2;
> > + goto fail;
> > }
> >
Re: [PATCH] Fix screen coud be filled with leftover artifacts
On Thu, Oct 03, 2024 at 09:17:46PM GMT, Askar Safin wrote:
> On Thu, 03 Oct 2024 11:23:08 +0400 Michael Chang via Grub-devel wrote
> ---
> > A regression in grub 2.12 causes the grub screen to become cluttered
>
> I just tested. Your patch doesn't fix anything for me!
Thank you for sharing the report. Let me try to explain what happened
here.
>
> (Note: I'm not GRUB developer, I'm just a user.)
>
> Hi. I'm annoyed by screen cluttering, too. So I applied this patch to see
> whether this will help.
> Unfortunately, it did not.
>
> Here is my test setup: I boot GRUB x86_64-efi in Qemu. My grub.cfg is so:
>
> echo "This is /EFI/debian/grub.cfg from main file system (iso9660)"
> echo "Testing shows that this file is loaded during UEFI-CD"
> sleep 10
>
>
> As you can see, my grub.cfg does "sleep 10" before GRUB command line. Also,
> note that there is no any "menuentry". So, menu is not shown.
>
> Okay, so what happens?
>
> Both with your patch and without your patch the following happens: I see
> message "This is /EFI/debian/grub.cfg from..." on screen with artifacts,
> then, after 10 seconds I switch to GRUB command line without artifacts.
To maintain the integrity of the flicker-free implementation, we cannot
enforce a universal clear screen to clean up any leftover artifacts at
the start. Therefore, if this doesn't occur automatically, you may need
to manually clear the screen by explicitly using the clear command, as
shown below:
clear
echo "This is /EFI/debian/grub.cfg from main file system (iso9660)"
echo "Testing shows that this file is loaded during UEFI-CD"
sleep 10
Please note that the clear command above will not work if you are
testing without the patch, as there is an inactive period for any
screen clearing attempts before text output occurs.
>
> So, yes, artifacts are not present at GRUB command line screen, but they ARE
> present (both with and without your patch) before we switch to GRUB command
> line.
You won’t notice a difference because some text is output before falling
into the grub command line (CLI). As part of the flicker-less patch,
the text output reinstates the clear function, allowing the screen to
clear properly before entering the CLI by itself.
However, the issue I encountered was that no text was output before
entering the CLI. As a result, all the screen clearing done at the code
level before the CLI didn’t take effect, leading to a cluttered screen.
This is what the patch is intended to deal with.
I hope this clarifies the issue a bit.
Thanks,
Michael
>
> Now let me describe my exact setup for testing this.
>
> I checked out GRUB's master branch. Then I compiled it so (both with and
> without your branch) (in debian sid x86_64 docker):
>
> ***
> ./bootstrap
> ./configure --prefix=/opt/grub --with-platform=efi
> make
> make install
> ***
>
> Note that freshly built GRUB got to /opt/grub.
>
> Then I built ".efi" file so (inside debian sid x86_64 docker):
>
> ***
> /opt/grub/bin/grub-mkimage -O x86_64-efi -o /tmp/grub.efi -d
> /opt/grub/lib/grub/x86_64-efi -p /EFI/debian all_video boot cat configfile
> echo fat font gfxmenu gfxterm gfxterm_background help iso9660 loadenv ls
> memdisk minicmd normal part_msdos part_gpt regexp search sleep test true video
> ***
>
> Then I built ".iso" file by this script (inside debian sid x86_64 docker):
> ***
> #!/bin/bash
> # This script creates isohybrid disk, which supports UEFI booting
> # The disk can be used both as CD image and as USB disk image
> # So, in total 2 boot modes are supported: UEFI-CD and UEFI-USB
> {
> # This is just boilerplate I insert to all my bash scripts
> set -e
> set -u
> set -o pipefail
> shopt -s inherit_errexit
> shopt -s nullglob
> export LC_ALL=C.UTF-8
>
> if [ $# != 1 ]; then
> echo "Usage: ${0##*/} OUT" >&2
> exit 1
> fi
>
> OUT="$1"
>
> DIR="$(mktemp -d /tmp/grub-XX)"
>
> mkdir -p "$DIR/esp/EFI/boot" "$DIR/esp/EFI/debian"
> "$DIR/main-root/EFI/debian" "$DIR/main-root/boot/grub"
> wget -O "$DIR/esp/EFI/boot/bootx64.efi"
> 'https://sources.debian.org/src/shim-signed/latest/shimx64.efi.signed/'
> mv /tmp/grub.efi "$DIR/esp/EFI/boot/grubx64.efi"
> cat << "EOF" > "$DIR/esp/EFI/debian/grub.cfg"
> echo "This is /EFI/debian/grub.cfg from ESP"
> echo "Testing shows that this file is loaded during UEFI-USB"
> sleep 10
> EOF
> mkfs.vfat -C "$DIR/main-root/bo
[PATCH] tpm: Skip loopback image measurement
The loopback image is configured to function as a disk by being mapped
as a block device. Instead of measuring the entire block device, we
should focus on tracking the individual files accessed from it. For
example, we do not directly measure block devices like disk hd0, but the
files opened from it.
This method is important to avoid running out of memory, since loopback
images can be very large. Trying to read and measure the whole image at
once could cause out of memory errors and disrupt the boot process.
Signed-Off-by: Michael Chang
---
grub-core/commands/tpm.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/grub-core/commands/tpm.c b/grub-core/commands/tpm.c
index 324423ef8..2350d660d 100644
--- a/grub-core/commands/tpm.c
+++ b/grub-core/commands/tpm.c
@@ -36,6 +36,16 @@ grub_tpm_verify_init (grub_file_t io,
{
*context = io->name;
*flags |= GRUB_VERIFY_FLAGS_SINGLE_CHUNK;
+
+ /*
+ * The loopback image is mapped as a disk, allowing it to function like a
+ * block device. However, we measure the files read from the block device,
+ * not the device itself. For example, we don't measure block devices like
+ * disk hd0 directly. This process is crucial to prevent out-of-memory
+ * errors, as loopback images are inherently large.
+ */
+ if ((type & GRUB_FILE_TYPE_MASK) == GRUB_FILE_TYPE_LOOPBACK)
+*flags = GRUB_VERIFY_FLAGS_SKIP_VERIFICATION;
return GRUB_ERR_NONE;
}
--
2.46.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Fix screen coud be filled with leftover artifacts
A regression in grub 2.12 causes the grub screen to become cluttered
with artifacts from the previous screen, whether it's the UEFI post ui,
UEFI shell, or any graphical UI running before grub. this issue occurs
in situations like booting grub from the UEFI shell and going straight
to the rescue or command shell, causing visual discomfort.
The regression was introduced by commit 2d7c3abd8 (efi/console: Do not
set text-mode until it is actually needed). To address the screen
flickering issue, this commit suppresses the text-mode setting until the
first output is requested. Before text-mode is set, any attempt to clear
the screen has no effect. This inactive period renders the clear screen
ineffective in early boot stages, potentially leaving leftover artifacts
that will clutter the grub console display, as there is no guarantee
there will always be a clear screen after the first output.
The issue is fixed by ensuring grub_console_cls() to work through lazy
mode-setting, while also avoiding screen clearing for the hidden menu,
which the flicker-free patch aims to improve.
Fixes: 2d7c3abd8 (efi/console: Do not set text-mode until we actually need it)
Signed-off-by: Michael Chang
---
grub-core/normal/menu.c | 7 ---
grub-core/term/efi/console.c | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/grub-core/normal/menu.c b/grub-core/normal/menu.c
index 6a90e091f..f24544b27 100644
--- a/grub-core/normal/menu.c
+++ b/grub-core/normal/menu.c
@@ -881,13 +881,14 @@ show_menu (grub_menu_t menu, int nested, int autobooted)
if (! e)
continue; /* Menu is empty. */
- grub_cls ();
-
if (auto_boot)
grub_menu_execute_with_fallback (menu, e, autobooted,
&execution_callback, ¬ify_boot);
else
- grub_menu_execute_entry (e, 0);
+ {
+ grub_cls ();
+ grub_menu_execute_entry (e, 0);
+ }
if (autobooted)
break;
}
diff --git a/grub-core/term/efi/console.c b/grub-core/term/efi/console.c
index bb587f39d..258b52737 100644
--- a/grub-core/term/efi/console.c
+++ b/grub-core/term/efi/console.c
@@ -432,7 +432,7 @@ grub_console_cls (struct grub_term_output *term
__attribute__ ((unused)))
grub_efi_simple_text_output_interface_t *o;
grub_efi_int32_t orig_attr;
- if (grub_efi_is_finished || text_mode != GRUB_TEXT_MODE_AVAILABLE)
+ if (grub_prepare_for_text_output (term) != GRUB_ERR_NONE)
return;
o = grub_efi_system_table->con_out;
--
2.46.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] lvm: allocate metadata buffer from raw contents
Previously, the buffer for LVM metadata parsing was set to twice the
size of the metadata area, which caused excessive memory use.
This patch changes the allocation to read the actual raw metadata blocks
directly from the metadata area. Instead of using twice the entire
metadata area size, we now allocate just what’s needed for the raw
metadata.
This change effectively reduces the buffer size while still working
correctly. In my test system on openSUSE, the buffer size for LVM
metadata dropped from 2,088,960 bytes to 1,119 bytes, which is a big
improvement.
Signed-off-by: Michael Chang
---
grub-core/disk/lvm.c | 79
1 file changed, 43 insertions(+), 36 deletions(-)
diff --git a/grub-core/disk/lvm.c b/grub-core/disk/lvm.c
index 0c32c95f9..ea260b47e 100644
--- a/grub-core/disk/lvm.c
+++ b/grub-core/disk/lvm.c
@@ -140,9 +140,11 @@ grub_lvm_detect (grub_disk_t disk,
grub_err_t err;
grub_uint64_t mda_offset, mda_size;
grub_size_t ptr;
+ grub_uint64_t mda_raw_offset, mda_raw_size;
char buf[GRUB_LVM_LABEL_SIZE];
char vg_id[GRUB_LVM_ID_STRLEN+1];
char pv_id[GRUB_LVM_ID_STRLEN+1];
+ char mdah_buf[sizeof (struct grub_lvm_mda_header) + sizeof (struct
grub_lvm_raw_locn)];
char *metadatabuf, *mda_end, *vgname;
const char *p, *q;
struct grub_lvm_label_header *lh = (struct grub_lvm_label_header *) buf;
@@ -220,21 +222,15 @@ grub_lvm_detect (grub_disk_t disk,
dlocn++;
mda_offset = grub_le_to_cpu64 (dlocn->offset);
- mda_size = grub_le_to_cpu64 (dlocn->size);
/* It's possible to have multiple copies of metadata areas, we just use the
first one. */
-
- /* Allocate buffer space for the circular worst-case scenario. */
- metadatabuf = grub_calloc (2, mda_size);
- if (! metadatabuf)
+ err = grub_disk_read (disk, 0, mda_offset, sizeof (mdah_buf), mdah_buf);
+ if (err)
goto fail;
- err = grub_disk_read (disk, 0, mda_offset, mda_size, metadatabuf);
- if (err)
-goto fail2;
+ mdah = (struct grub_lvm_mda_header *) mdah_buf;
- mdah = (struct grub_lvm_mda_header *) metadatabuf;
if ((grub_strncmp ((char *)mdah->magic, GRUB_LVM_FMTT_MAGIC,
sizeof (mdah->magic)))
|| (grub_le_to_cpu32 (mdah->version) != GRUB_LVM_FMTT_VERSION))
@@ -244,42 +240,58 @@ grub_lvm_detect (grub_disk_t disk,
#ifdef GRUB_UTIL
grub_util_info ("unknown LVM metadata header");
#endif
- goto fail2;
+ goto fail;
}
rlocn = mdah->raw_locns;
- if (grub_le_to_cpu64 (rlocn->offset) >= grub_le_to_cpu64 (mda_size))
+
+ mda_size = grub_le_to_cpu64 (mdah->size);
+ mda_raw_size = grub_le_to_cpu64 (rlocn->size);
+ mda_raw_offset = grub_le_to_cpu64 (rlocn->offset);
+
+ if (mda_raw_offset >= mda_size)
{
#ifdef GRUB_UTIL
grub_util_info ("metadata offset is beyond end of metadata area");
#endif
- goto fail2;
+ goto fail;
}
- if (grub_le_to_cpu64 (rlocn->offset) + grub_le_to_cpu64 (rlocn->size) >
- grub_le_to_cpu64 (mdah->size))
+ metadatabuf = grub_malloc (mda_raw_size);
+
+ if (! metadatabuf)
+goto fail;
+
+ if (mda_raw_offset + mda_raw_size > mda_size)
{
- if (2 * mda_size < GRUB_LVM_MDA_HEADER_SIZE ||
- (grub_le_to_cpu64 (rlocn->offset) + grub_le_to_cpu64 (rlocn->size) -
- grub_le_to_cpu64 (mdah->size) > mda_size - GRUB_LVM_MDA_HEADER_SIZE))
- {
-#ifdef GRUB_UTIL
- grub_util_info ("cannot copy metadata wrap in circular buffer");
-#endif
- goto fail2;
- }
+ err = grub_disk_read (disk, 0,
+ mda_offset + mda_raw_offset,
+ mda_size - mda_raw_offset,
+ metadatabuf);
+ if (err)
+ goto fail2;
/* Metadata is circular. Copy the wrap in place. */
- grub_memcpy (metadatabuf + mda_size,
- metadatabuf + GRUB_LVM_MDA_HEADER_SIZE,
- grub_le_to_cpu64 (rlocn->offset) +
- grub_le_to_cpu64 (rlocn->size) -
- grub_le_to_cpu64 (mdah->size));
+ err = grub_disk_read (disk, 0,
+ mda_offset + GRUB_LVM_MDA_HEADER_SIZE,
+ mda_raw_offset + mda_raw_size - mda_size,
+ metadatabuf + mda_size - mda_raw_offset);
+ if (err)
+ goto fail2;
+}
+ else
+{
+ err = grub_disk_read (disk, 0,
+ mda_offset + mda_raw_offset,
+ mda_raw_size,
+ metadatabuf);
+ if (err)
+ goto fail2;
}
- if (grub_add ((grub_size_t)metadatabuf,
- (grub_size_t)grub_le_to_cpu64 (rlocn->offset),
- &ptr))
+ p = q = metadatabuf;
+
+ if (grub_add ((grub_size_t)metadatabuf, (grub_size_t)mda_raw_size, &ptr))
{
error_parsing_metadata:
#ifdef GRUB_UTIL
@@ -288,11 +300,6 @@ grub_lvm_detect (grub_disk_t disk,
goto fail2;
}
- p = q = (char *)ptr;
-
- i
[PATCH] efinet: Skip virtual VLAN devices during card enumeration
Similar to the fix in commit "c52ae4057 efinet: skip virtual IPv4 and
IPv6 devices during card enumeration", the UEFI PXE driver creates
additional VLAN child devices when a VLAN ID is configured on a network
interface associated with a physical NIC. These virtual VLAN devices
must be skipped during card enumeration to ensure that the subsequent
SNP exclusive open operation targets the correct physical card
instances, otherwise packet transfer would fail.
Example device path with VLAN nodes:
/MAC(123456789ABC,0x1)/Vlan(20)/IPv4(0.0.0.0,0x0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)
Signed-Off-by: Michael Chang
---
grub-core/net/drivers/efi/efinet.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/grub-core/net/drivers/efi/efinet.c
b/grub-core/net/drivers/efi/efinet.c
index 3ea25cf98..58fe381ab 100644
--- a/grub-core/net/drivers/efi/efinet.c
+++ b/grub-core/net/drivers/efi/efinet.c
@@ -276,7 +276,8 @@ grub_efinet_findcards (void)
|| GRUB_EFI_DEVICE_PATH_SUBTYPE (child) ==
GRUB_EFI_IPV6_DEVICE_PATH_SUBTYPE)
&& parent
&& GRUB_EFI_DEVICE_PATH_TYPE (parent) ==
GRUB_EFI_MESSAGING_DEVICE_PATH_TYPE
- && GRUB_EFI_DEVICE_PATH_SUBTYPE (parent) ==
GRUB_EFI_MAC_ADDRESS_DEVICE_PATH_SUBTYPE)
+ && (GRUB_EFI_DEVICE_PATH_SUBTYPE (parent) ==
GRUB_EFI_MAC_ADDRESS_DEVICE_PATH_SUBTYPE
+ || GRUB_EFI_DEVICE_PATH_SUBTYPE (parent) ==
GRUB_EFI_VLAN_DEVICE_PATH_SUBTYPE))
continue;
net = grub_efi_open_protocol (*handle, &net_io_guid,
@@ -389,6 +390,15 @@ grub_efi_net_config_real (grub_efi_handle_t hnd, char
**device,
dup_ldp->type = GRUB_EFI_END_DEVICE_PATH_TYPE;
dup_ldp->subtype = GRUB_EFI_END_ENTIRE_DEVICE_PATH_SUBTYPE;
dup_ldp->length = sizeof (*dup_ldp);
+
+ dup_ldp = grub_efi_find_last_device_path (dup_dp);
+ if (GRUB_EFI_DEVICE_PATH_SUBTYPE (dup_ldp) ==
GRUB_EFI_VLAN_DEVICE_PATH_SUBTYPE)
+ {
+ dup_ldp->type = GRUB_EFI_END_DEVICE_PATH_TYPE;
+ dup_ldp->subtype = GRUB_EFI_END_ENTIRE_DEVICE_PATH_SUBTYPE;
+ dup_ldp->length = sizeof (*dup_ldp);
+ }
+
match = grub_efi_compare_device_paths (dup_dp, cdp) == 0;
grub_free (dup_dp);
if (!match)
--
2.46.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2] bli: Fix crash in get_part_uuid
The get_part_uuid() function made an assumption that the target grub
device is a partition device and accessed device->disk->partition
without checking for NULL. There are four situations where this
assumption is problematic:
1. The device is a net device instead of a disk.
2. The device is an abstraction device, like LVM, RAID, or CRYPTO, which
is mostly logical "disk" ((lvmid/) and so on).
3. Firmware RAID may present the ESP to grub as an EFI disk (hd0) device
if it is contained within a Linux software RAID.
4. When booting from a cdrom, the ESP is a vfat image indexed by the El
Torito boot catalog. The boot device is set to (cd0), corresponding
to the cdrom image mounted as an iso9660 filesystem.
As a result, get_part_uuid() could lead to a NULL pointer dereference
and trigger a synchronous exception during boot if the ESP falls into
one of these categories. This patch fixes the problem by adding the
necessary checks to handle cases where the ESP is not a partition
device.
Additionally, to avoid disrupting the boot process, this patch relaxes
the severity of the errors in this context to non-critical. Errors will
be logged, but they will not prevent the boot process from continuing.
Fixes: e0fa7dc84 (bli: Add a module for the Boot Loader Interface)
Signed-off-by: Michael Chang
Reviewed-By: Oliver Steffen
---
grub-core/commands/bli.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/grub-core/commands/bli.c b/grub-core/commands/bli.c
index e0d8a54f7..298c5f70a 100644
--- a/grub-core/commands/bli.c
+++ b/grub-core/commands/bli.c
@@ -48,6 +48,22 @@ get_part_uuid (const char *device_name, char **part_uuid)
if (device == NULL)
return grub_error (grub_errno, N_("cannot open device: %s"), device_name);
+ if (device->disk == NULL)
+{
+ grub_dprintf ("bli", "%s is not a disk device, partuuid skipped\n",
device_name);
+ *part_uuid = NULL;
+ grub_device_close (device);
+ return GRUB_ERR_NONE;
+}
+
+ if (device->disk->partition == NULL)
+{
+ grub_dprintf ("bli", "%s has no partition, partuuid skipped\n",
device_name);
+ *part_uuid = NULL;
+ grub_device_close (device);
+ return GRUB_ERR_NONE;
+}
+
disk = grub_disk_open (device->disk->name);
if (disk == NULL)
{
@@ -99,7 +115,7 @@ set_loader_device_part_uuid (void)
status = get_part_uuid (device_name, &part_uuid);
- if (status == GRUB_ERR_NONE)
+ if (status == GRUB_ERR_NONE && part_uuid)
status = grub_efi_set_variable_to_string ("LoaderDevicePartUUID",
&bli_vendor_guid, part_uuid,
GRUB_EFI_VARIABLE_BOOTSERVICE_ACCESS |
GRUB_EFI_VARIABLE_RUNTIME_ACCESS);
@@ -117,4 +133,6 @@ GRUB_MOD_INIT (bli)
GRUB_EFI_VARIABLE_BOOTSERVICE_ACCESS |
GRUB_EFI_VARIABLE_RUNTIME_ACCESS);
set_loader_device_part_uuid ();
+ /* No error here is critical, other than being logged */
+ grub_print_error ();
}
--
2.45.2
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] bli: Fix crash in get_part_uuid
On Tue, Jul 16, 2024 at 05:45:10AM GMT, Oliver Steffen wrote:
> Quoting Michael Chang via Grub-devel (2024-07-16 08:55:00)
> > The get_part_uuid() function made an assumption that the target grub
> > device is a partition device and accessed device->disk->partition
> > without checking for NULL. There are four situations where this
> > assumption is problematic:
> >
> > 1. The device is a net device instead of a disk.
> > 2. The device is an abstraction device, like LVM, RAID, or CRYPTO, which
> >is mostly logical "disk" ((lvmid/) and so on).
> > 3. Firmware RAID may present the ESP to grub as an EFI disk (hd0) device
> >if it is contained within a Linux software RAID.
> > 4. When booting from an ISO, the ESP is treated as an El Torito image in
> >the boot catalog. It is therefore presented by firmware and
> >interpreted by grub as a disk (cd0).
> >
> > As a result, get_part_uuid() could lead to a NULL pointer dereference
> > and trigger a synchronous exception during boot if the ESP falls into
> > one of these categories. This patch fixes the problem by adding the
> > necessary checks to handle cases where the ESP is not a partition
> > device.
> >
> > Additionally, to avoid disrupting the boot process, this patch relaxes
> > the severity of the errors in this context to non-critical. Errors will
> > be logged, but they will not prevent the boot process from continuing.
> >
> > Fixes: e0fa7dc84 (bli: Add a module for the Boot Loader Interface)
> > Signed-off-by: Michael Chang
> > ---
> > grub-core/commands/bli.c | 20 +++-
> > 1 file changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/grub-core/commands/bli.c b/grub-core/commands/bli.c
> > index e0d8a54f7..298c5f70a 100644
> > --- a/grub-core/commands/bli.c
> > +++ b/grub-core/commands/bli.c
> > @@ -48,6 +48,22 @@ get_part_uuid (const char *device_name, char **part_uuid)
> >if (device == NULL)
> > return grub_error (grub_errno, N_("cannot open device: %s"),
> > device_name);
> >
> > + if (device->disk == NULL)
> > +{
> > + grub_dprintf ("bli", "%s is not a disk device, partuuid skipped\n",
> > device_name);
> > + *part_uuid = NULL;
> > + grub_device_close (device);
> > + return GRUB_ERR_NONE;
> > +}
> > +
> > + if (device->disk->partition == NULL)
> > +{
> > + grub_dprintf ("bli", "%s has no partition, partuuid skipped\n",
> > device_name);
> > + *part_uuid = NULL;
> > + grub_device_close (device);
> > + return GRUB_ERR_NONE;
> > +}
> > +
> >disk = grub_disk_open (device->disk->name);
> >if (disk == NULL)
> > {
> > @@ -99,7 +115,7 @@ set_loader_device_part_uuid (void)
> >
> >status = get_part_uuid (device_name, &part_uuid);
> >
> > - if (status == GRUB_ERR_NONE)
> > + if (status == GRUB_ERR_NONE && part_uuid)
> > status = grub_efi_set_variable_to_string ("LoaderDevicePartUUID",
> > &bli_vendor_guid, part_uuid,
> >
> > GRUB_EFI_VARIABLE_BOOTSERVICE_ACCESS |
> >
> > GRUB_EFI_VARIABLE_RUNTIME_ACCESS);
> > @@ -117,4 +133,6 @@ GRUB_MOD_INIT (bli)
> >GRUB_EFI_VARIABLE_BOOTSERVICE_ACCESS |
> >GRUB_EFI_VARIABLE_RUNTIME_ACCESS);
> >set_loader_device_part_uuid ();
> > + /* No error here is critical, other than being logged */
> > + grub_print_error ();
> > }
> > --
> > 2.45.2
> >
> >
>
> Reviewed-By: Oliver Steffen
Thank you! I'll add your Reviewed-By in next revision.
Regards,
Michael
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI El Torito image on ISO9660 (was: [PATCH] bli: Fix crash in get_part_uuid)
On Tue, Jul 16, 2024 at 10:47:57AM GMT, Pascal Hambourg wrote: > On 16/07/2024 at 08:55, Michael Chang via Grub-devel wrote: > > > > 4. When booting from an ISO, the ESP is treated as an El Torito image in > > the boot catalog. It is therefore presented by firmware and > > interpreted by grub as a disk (cd0). > > In my limited experience, (cd0) is the whole CD/DVD/BD and GRUB does not > show the EFI El Torito image as such. > > Tested with debian-12.6.0-amd64-netinst.iso on QEMU+OVMF and real hardware: > > grub> echo $cmdpath > (cd0)/EFI/BOOT > > grub> ls > (proc) (memdisk) (cd0) (cd0,apple2) (cd0,apple1) (cd0,msdos2) > > grub> ls (cd0) > Device cd0: Filesystem type iso9660 - Label 'Debian 12.6.0 amd64 n' ... > > grub> ls (cd0)/ > /boot /css /debian /dists /doc /EFI ... > > The /EFI directory in the ISO9660 filesystem contains a copy of the EFI El > Torito image contents so that GRUB can find its config file > (cd0)/EFI/debian/grub.cfg. Thank you for pointing this out. You're right, (cd0) is actually the whole cdrom image mounted by the iso9660 filesystem in grub, not the vfat EFI image. I'll fix the commit message in the next revision. > > The Apple and MSDOS partitions are caused by the hybrid structure of the > Debian installation image. Partition (cd0,apple2) matches the position of > the EFI El Torito image but would not exist on a "pure" ISO9660 image. It seems that saying "When booting from an ISO..." is ambiguous because it also includes booting hybrid disk ISO images. In this context, bli wouldn't crash since $cmdpath, the source of the boot location, points to a partition device. To be more precise, I'll rephrase it to "When booting from a cdrom...". Thanks, Michael ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] bli: Fix crash in get_part_uuid
The get_part_uuid() function made an assumption that the target grub
device is a partition device and accessed device->disk->partition
without checking for NULL. There are four situations where this
assumption is problematic:
1. The device is a net device instead of a disk.
2. The device is an abstraction device, like LVM, RAID, or CRYPTO, which
is mostly logical "disk" ((lvmid/) and so on).
3. Firmware RAID may present the ESP to grub as an EFI disk (hd0) device
if it is contained within a Linux software RAID.
4. When booting from an ISO, the ESP is treated as an El Torito image in
the boot catalog. It is therefore presented by firmware and
interpreted by grub as a disk (cd0).
As a result, get_part_uuid() could lead to a NULL pointer dereference
and trigger a synchronous exception during boot if the ESP falls into
one of these categories. This patch fixes the problem by adding the
necessary checks to handle cases where the ESP is not a partition
device.
Additionally, to avoid disrupting the boot process, this patch relaxes
the severity of the errors in this context to non-critical. Errors will
be logged, but they will not prevent the boot process from continuing.
Fixes: e0fa7dc84 (bli: Add a module for the Boot Loader Interface)
Signed-off-by: Michael Chang
---
grub-core/commands/bli.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/grub-core/commands/bli.c b/grub-core/commands/bli.c
index e0d8a54f7..298c5f70a 100644
--- a/grub-core/commands/bli.c
+++ b/grub-core/commands/bli.c
@@ -48,6 +48,22 @@ get_part_uuid (const char *device_name, char **part_uuid)
if (device == NULL)
return grub_error (grub_errno, N_("cannot open device: %s"), device_name);
+ if (device->disk == NULL)
+{
+ grub_dprintf ("bli", "%s is not a disk device, partuuid skipped\n",
device_name);
+ *part_uuid = NULL;
+ grub_device_close (device);
+ return GRUB_ERR_NONE;
+}
+
+ if (device->disk->partition == NULL)
+{
+ grub_dprintf ("bli", "%s has no partition, partuuid skipped\n",
device_name);
+ *part_uuid = NULL;
+ grub_device_close (device);
+ return GRUB_ERR_NONE;
+}
+
disk = grub_disk_open (device->disk->name);
if (disk == NULL)
{
@@ -99,7 +115,7 @@ set_loader_device_part_uuid (void)
status = get_part_uuid (device_name, &part_uuid);
- if (status == GRUB_ERR_NONE)
+ if (status == GRUB_ERR_NONE && part_uuid)
status = grub_efi_set_variable_to_string ("LoaderDevicePartUUID",
&bli_vendor_guid, part_uuid,
GRUB_EFI_VARIABLE_BOOTSERVICE_ACCESS |
GRUB_EFI_VARIABLE_RUNTIME_ACCESS);
@@ -117,4 +133,6 @@ GRUB_MOD_INIT (bli)
GRUB_EFI_VARIABLE_BOOTSERVICE_ACCESS |
GRUB_EFI_VARIABLE_RUNTIME_ACCESS);
set_loader_device_part_uuid ();
+ /* No error here is critical, other than being logged */
+ grub_print_error ();
}
--
2.45.2
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 3/6] ieee1275: implement FCP methods for WWPN and LUNs
On Thu, Jun 06, 2024 at 06:07:24PM GMT, Avnish Chouhan wrote:
> This patch enables the fcp-targets and fcp-luns methods which are
> responsible to get WWPNs and LUNs for fibre channel devices.
>
> Those methods are specially necessary if the boot directory and grub
> installation are in different FCP disks, allowing the dev_iterate()
> to find the WWPNs and LUNs when called by searchfs.uuid tool.
>
> Signed-off-by: Diego Domingos
> Signed-off-by: Avnish Chouhan
> ---
> grub-core/disk/ieee1275/ofdisk.c | 111
> ++-
> 1 file changed, 110 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/disk/ieee1275/ofdisk.c
> b/grub-core/disk/ieee1275/ofdisk.c
> index 5534684..5958e5e 100644
> --- a/grub-core/disk/ieee1275/ofdisk.c
> +++ b/grub-core/disk/ieee1275/ofdisk.c
> @@ -209,7 +209,116 @@ dev_iterate_real (const char *name, const char *path)
> static void
> dev_iterate (const struct grub_ieee1275_devalias *alias)
> {
> - if (grub_strcmp (alias->type, "vscsi") == 0)
> + if (grub_strcmp (alias->type, "fcp") == 0)
> +{
> + /*
> + * If we are dealing with fcp devices, we need
> + * to find the WWPNs and LUNs to iterate them
> + */
> + grub_ieee1275_ihandle_t ihandle;
> + grub_uint64_t *ptr_targets, *ptr_luns, k, l;
> + unsigned int i, j, pos;
> + char *buf, *bufptr;
> + struct set_fcp_targets_args
> + {
> +struct grub_ieee1275_common_hdr common;
> +grub_ieee1275_cell_t method;
> +grub_ieee1275_cell_t ihandle;
> +grub_ieee1275_cell_t catch_result;
> +grub_ieee1275_cell_t nentries;
> +grub_ieee1275_cell_t table;
> + } args_targets;
> +
> + struct set_fcp_luns_args
> + {
> +struct grub_ieee1275_common_hdr common;
> +grub_ieee1275_cell_t method;
> +grub_ieee1275_cell_t ihandle;
> +grub_ieee1275_cell_t wwpn_h;
> +grub_ieee1275_cell_t wwpn_l;
> +grub_ieee1275_cell_t catch_result;
> +grub_ieee1275_cell_t nentries;
> +grub_ieee1275_cell_t table;
> + } args_luns;
> +
> + struct args_ret
> + {
> +grub_uint64_t addr;
> +grub_uint64_t len;
> + };
> +
> + if (grub_ieee1275_open (alias->path, &ihandle))
> +{
> + grub_dprintf ("disk", "failed to open the disk while iterating FCP
> disk path=%s\n", alias->path);
> + return;
> +}
> +
> + /* Setup the fcp-targets method to call via pfw*/
> + INIT_IEEE1275_COMMON (&args_targets.common, "call-method", 2, 3);
> + args_targets.method = (grub_ieee1275_cell_t) "fcp-targets";
> + args_targets.ihandle = ihandle;
> +
> + /* Setup the fcp-luns method to call via pfw */
> + INIT_IEEE1275_COMMON (&args_luns.common, "call-method", 4, 3);
> + args_luns.method = (grub_ieee1275_cell_t) "fcp-luns";
> + args_luns.ihandle = ihandle;
> + if (IEEE1275_CALL_ENTRY_FN (&args_targets) == -1)
> +{
> + grub_dprintf ("disk", "failed to get the targets while iterating
> FCP disk path=%s\n", alias->path);
> + grub_ieee1275_close (ihandle);
> + return;
> +}
> + buf = grub_malloc (grub_strlen (alias->path) + 32 + 32);
> + if (!buf)
> +{
> + grub_ieee1275_close (ihandle);
> + return;
> +}
> + bufptr = grub_stpcpy (buf, alias->path);
> +
> + /*
> + * Iterate over entries returned by pfw. Each entry contains a
> + * pointer to wwpn table and his length.
> + */
> + struct args_ret *targets_table = (struct args_ret *)
> (args_targets.table);
> + for (i = 0; i < args_targets.nentries; i++)
> +{
> + ptr_targets = (grub_uint64_t*) (grub_uint32_t)
> targets_table[i].addr;
I believe a comment is needed here to explain why it is necessary to
truncate the 64-bit address into 32-bit. It appears that losing the
higher 32 bits is intentional.
> + /* Iterate over all wwpns in given table */
> + for(k = 0; k < targets_table[i].len; k++)
> +{
> + args_luns.wwpn_l = (grub_ieee1275_cell_t) (*ptr_targets);
> + args_luns.wwpn_h = (grub_ieee1275_cell_t) (*ptr_targets >> 32);
> + pos = grub_snprintf (bufptr, 32, "/disk@%" PRIxGRUB_UINT64_T,
> + *ptr_targets++);
As long as ptr_targets holds a pointer external to grub, the alignment
is neither validated nor guaranteed. IMHO it is safer to use
grub_get_unaligned64(ptr_targets++).
> + /* Get the luns for given wwpn target */
> + if (IEEE1275_CALL_ENTRY_FN (&args_luns) == -1)
> +{
> + grub_dprintf ("disk", "failed to get the LUNS while
> iterating FCP disk path=%s\n", buf);
> + grub_ieee1275_close (ihandle);
> + grub_free (buf);
> + return;
> +}
> +
Re: [PATCH v3 1/6] ieee1275/powerpc: implements fibre channel discovery for ofpathname
On Thu, Jun 06, 2024 at 06:07:22PM GMT, Avnish Chouhan wrote:
> grub-ofpathname doesn't work with fibre channel because there is no
> function currently implemented for it.
> This patch enables it by prividing a function that looks for the port
> name, building the entire path for OF devices.
>
> Signed-off-by: Diego Domingos
> Signed-off-by: Avnish Chouhan
> ---
> grub-core/osdep/linux/ofpath.c | 49
> ++
> 1 file changed, 49 insertions(+)
>
> diff --git a/grub-core/osdep/linux/ofpath.c b/grub-core/osdep/linux/ofpath.c
> index a6153d35954..0f5d54e9f2d 100644
> --- a/grub-core/osdep/linux/ofpath.c
> +++ b/grub-core/osdep/linux/ofpath.c
> @@ -350,6 +350,38 @@ of_path_of_ide(const char *sys_devname
> __attribute__((unused)), const char *devi
>return ret;
> }
>
> +
> +static void
> +of_fc_port_name (const char *path, const char *subpath, char *port_name)
> +{
> + char *bname, *basepath, *p;
> + int fd;
> +
> + bname = xmalloc (sizeof (char) * 150);
Why not `char bname[150]` for simplicty ? Is there any reason behind the magic
number
150?
> + basepath = xmalloc (strlen (path));
> +
> + /* Generate the path to get port name information from the drive */
> + strncpy (basepath, path, subpath-path);
> + basepath[subpath-path - 1] = '\0';
I think it can be replaced by `strndup()` for simplicity.
> + p = get_basename (basepath);
> + snprintf (bname, sizeof (char) * 150, "%s/fc_transport/%s/port_name",
> basepath, p);
> +
> + /* Read the information from the port name */
> + fd = open (bname, O_RDONLY);
> + if (fd < 0)
> +grub_util_error (_("cannot open `%s': %s"), bname, strerror (errno));
> +
> + if (read (fd, port_name, sizeof (char) *19) < 0)
> +grub_util_error (_("cannot read `%s': %s"), bname, strerror (errno));
The caller has the port_name's size set to `sizeof (char) * 17`, the
read() may really be overreading, and overflowing port_name.
Moreover the function didn't have a way to check to size of port_name.
> +
> + sscanf (port_name, "0x%s", port_name);
> +
> + close (fd);
> +
> + free (bname);
> + free (basepath);
> +}
> +
> #ifdef __sparc__
> static char *
> of_path_of_nvme(const char *sys_devname __attribute__((unused)),
> @@ -577,6 +609,16 @@ of_path_of_scsi(const char *sys_devname
> __attribute__((unused)), const char *dev
>digit_string = trailing_digits (device);
>if (strncmp (of_path, "/vdevice/", sizeof ("/vdevice/") - 1) == 0)
> {
> + if (strstr (of_path, "vfc-client"))
> +{
> +char * port_name = xmalloc (sizeof (char) * 17);
Again why not `char port_name[17]` ? And lacking of description for
magic number 17.
> +of_fc_port_name (sysfs_path, p, port_name);
Please add an argument, port_name_size, for boundary checking in
of_fc_port_name().
> +
> + snprintf (disk, sizeof (disk), "/%s@%s", disk_name, port_name);
> +free (port_name);
> +}
> + else
> +{
>unsigned long id = 0x8000 | (tgt << 8) | (bus << 5) | lun;
>if (*digit_string == '\0')
> {
> @@ -590,6 +632,13 @@ of_path_of_scsi(const char *sys_devname
> __attribute__((unused)), const char *dev
> snprintf(disk, sizeof (disk),
> "/%s@%04lx:%c", disk_name, id, 'a' + (part - 1));
> }
> + }
> +} else if (strstr (of_path, "fibre-channel") || (strstr (of_path,
> "vfc-client"))){
> +char * port_name = xmalloc (sizeof (char) * 17);
> +of_fc_port_name (sysfs_path, p, port_name);
> +
> + snprintf (disk, sizeof (disk), "/%s@%s", disk_name, port_name);
> + free (port_name);
Ditto.
Thanks,
Michael
> }
>else
> {
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 2/6] ieee1275/powerpc: enables device mapper discovery
On Thu, Jun 20, 2024 at 03:14:59PM GMT, avnish wrote:
> Hi Vladimir,
>
> We have implemented this code to enable the ieee1275 hint for grub. We had
> scenarios (in SLES) like the disk had PReP partition followed by an LVM and,
> inside this LVM , the boot partition. So, we implemented this code to make
> grub able to generate the hint. Without this code, we were unable to find
> the hint for the boot process. And, in some scenarios, due the amount of
> disks in the machine, the process could take a lot to finish.
As Vladimir pointed out, the correct search hint should be lvmid/,
so grub will try to assemble the root logical volume first in the
process of looking up the root file system. This way, time won't be
wasted on trying those OpenFirmware raw disks, as they are not the
target.
The problem here is that bringing up the logical volume itself can be
very slow, and grub lacks measures like an LVM filter, which would help
to restrict which devices are scanned and improve performance. In the
end, the patch doesn't help either way.
In my opinion, this patch is more about updating the system bootlist
than achieving the proclaimed boot time enhancement.
Thanks,
Michael
> Shall we limit this function call specific to PowerPC? Something like this
> below:
>
> #ifdef __powerpc__
> realname = get_slave_from_dm (name_buf);
> if (realname)
> {
> free (name_buf);
> name_buf = realname;
> }
> #endif
>
> Please suggest us.
> Thank you so much!
>
> Regards,
> Avnish Chouhan
>
>
> On 2024-06-07 15:05, grub-devel-requ...@gnu.org wrote:
> > Send Grub-devel mailing list submissions to
> > grub-devel@gnu.org
> > --
> >
> > Message: 4
> > Date: Fri, 7 Jun 2024 11:34:45 +0200
> > From: "Vladimir 'phcoder' Serbinenko"
> > To: avnish
> > Cc: The development of GNU GRUB , Daniel Kiper
> > , brk...@linux.ibm.com,
> > meghanaprak...@in.ibm.com, Diego Domingos
> > Subject: Re: [PATCH v3 2/6] ieee1275/powerpc: enables device mapper
> > discovery
> > Message-ID:
> >
> > Content-Type: text/plain; charset="utf-8"
> >
> > Le ven. 7 juin 2024, 10:34, avnish a écrit :
> >
> > > On 2024-06-06 21:04, Vladimir 'phcoder' Serbinenko wrote:
> > > > 2 problems: * How does dm device ends up on ofpathname? It should be
> > > > handled by grub internal logic in most cases and not end up in
> > > > of-specific paths * Why not use existing devmapper functions already
> > > > present in codebase? Le jeu. 6 juin 2024,
> > > > > 2 problems:
> > > > * How does dm device ends up on ofpathname? It should be handled by
> > > > grub internal logic in most cases and not end up in of-specific paths
> > > > * Why not use existing devmapper functions already present in
> > > > codebase?
> > > >
> > >
> > > Hi Vladimir,
> > > Thank you so much for your response!
> > >
> > > We have observed that whenever we are dealing with the devices like
> > > "/dev/dm-*", the ofpath returns null.
> > >
> > It's expected behavior
> >
> > > To resolve this, as no such required functions has been implemented to
> > > handle this kind of case. We have done changes based on the
> > > requirement
> > > that will look into /sys/block/dm-* devices and search slave
> > > devices recursively inside slaves directory to find the root disk.
> >
> > Installing on e.g. LVM is invalid. Only 3 cases can your approach work:
> > 1) multipath
> > 2) maybe RAID1 as well in some cases
> > 3) if ofw assembles raid somehow
> > Which one do you have? We need more details.
> > This patch enables invalid configs like installing on LVM
> >
> > >
> > > Regards,
> > > Avnish Chouhan
> > >
> > > > Le jeu. 6 juin 2024, 14:40, Avnish Chouhan a
> > > > écrit :
> > > >
> > > >> This patch enables the device mapper discovery on ofpath.c.
> > > >> Currently,
> > > >> when we are dealing with a device like /dev/dm-* the ofpath returns
> > > >> null
> > > >> since there is no function implemented to handle this case.
> > > >>
> > > >> This patch implements a function that will look into /sys/block/dm-*
> > > >> devices and search recursively inside slaves directory to find the
> > > >> root
> > > >> disk.
> > > >>
> > > >> Signed-off-by: Diego Domingos
> > > >> Signed-off-by: Avnish Chouhan
> > > >> ---
> > > >> grub-core/osdep/linux/ofpath.c | 64
> > > >> +-
> > > >> 1 file changed, 63 insertions(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/grub-core/osdep/linux/ofpath.c
> > > >> b/grub-core/osdep/linux/ofpath.c
> > > >> index 0f5d54e9f2d..cc849d9c94c 100644
> > > >> --- a/grub-core/osdep/linux/ofpath.c
> > > >> +++ b/grub-core/osdep/linux/ofpath.c
> > > >> @@ -37,6 +37,7 @@
> > > >> #include
> > > >> #include
> > > >> #include
> > > >> +#include
> > > >>
> > > >> #ifdef __sparc__
> > > >> typedef enum
> > > >> @@ -755,13 +756,74 @@ strip_trailing_digits (const char *p)
> > > >> return new;
> > > >> }
> > > >>
> > > >> +static char *
> > > >> +get_slave_from_dm (con
Re: [PATCH] Fix screen coud be filled with leftover artifacts
On Thu, Jun 20, 2024 at 02:48:55PM GMT, Michael Chang wrote: > A regression in grub 2.12 causes the grub screen to become cluttered > with artifacts from the previous screen, whether it's the UEFI post ui, > UEFI shell, or any graphical UI running before grub. this issue occurs > in situations like booting grub from the UEFI shell and going straight > to the rescue or command shell, causing visual discomfort. Here the captured screen to the issue happened: https://paste.opensuse.org/pastes/cbef185ed55c Thanks, Michael ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Fix screen coud be filled with leftover artifacts
A regression in grub 2.12 causes the grub screen to become cluttered
with artifacts from the previous screen, whether it's the UEFI post ui,
UEFI shell, or any graphical UI running before grub. this issue occurs
in situations like booting grub from the UEFI shell and going straight
to the rescue or command shell, causing visual discomfort.
The regression was introduced by commit 2d7c3abd8 (efi/console: Do not
set text-mode until it is actually needed). To address the screen
flickering issue, this commit suppresses the text-mode setting until the
first output is requested. Before text-mode is set, any attempt to clear
the screen has no effect. This inactive period renders the clear screen
ineffective in early boot stages, potentially leaving leftover artifacts
that will clutter the grub console display, as there is no guarantee
there will always be a clear screen after the first output.
The issue is fixed by ensuring grub_console_cls() to work through lazy
mode-setting, while also avoiding screen clearing for the hidden menu,
which the flicker-free patch aims to improve.
Fixes: 2d7c3abd8 (efi/console: Do not set text-mode until we actually need it)
Signed-off-by: Michael Chang
---
grub-core/normal/menu.c | 7 ---
grub-core/term/efi/console.c | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/grub-core/normal/menu.c b/grub-core/normal/menu.c
index 6a90e091f..f24544b27 100644
--- a/grub-core/normal/menu.c
+++ b/grub-core/normal/menu.c
@@ -881,13 +881,14 @@ show_menu (grub_menu_t menu, int nested, int autobooted)
if (! e)
continue; /* Menu is empty. */
- grub_cls ();
-
if (auto_boot)
grub_menu_execute_with_fallback (menu, e, autobooted,
&execution_callback, ¬ify_boot);
else
- grub_menu_execute_entry (e, 0);
+ {
+ grub_cls ();
+ grub_menu_execute_entry (e, 0);
+ }
if (autobooted)
break;
}
diff --git a/grub-core/term/efi/console.c b/grub-core/term/efi/console.c
index bb587f39d..258b52737 100644
--- a/grub-core/term/efi/console.c
+++ b/grub-core/term/efi/console.c
@@ -432,7 +432,7 @@ grub_console_cls (struct grub_term_output *term
__attribute__ ((unused)))
grub_efi_simple_text_output_interface_t *o;
grub_efi_int32_t orig_attr;
- if (grub_efi_is_finished || text_mode != GRUB_TEXT_MODE_AVAILABLE)
+ if (grub_prepare_for_text_output (term) != GRUB_ERR_NONE)
return;
o = grub_efi_system_table->con_out;
--
2.45.2
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] lvm: allocate metadata buffer from raw contents
Previously, the buffer for LVM metadata parsing was set to twice the
size of the metadata area, which caused excessive memory use.
This patch changes the allocation to read the actual raw metadata blocks
directly from the metadata area. Instead of using twice the entire
metadata area size, we now allocate just what’s needed for the raw
metadata.
This change effectively reduces the buffer size while still working
correctly. In my test system on openSUSE, the buffer size for LVM
metadata dropped from 2,088,960 bytes to 1,119 bytes, which is a big
improvement.
Signed-off-by: Michael Chang
---
grub-core/disk/lvm.c | 79
1 file changed, 43 insertions(+), 36 deletions(-)
diff --git a/grub-core/disk/lvm.c b/grub-core/disk/lvm.c
index 0c32c95f9..ea260b47e 100644
--- a/grub-core/disk/lvm.c
+++ b/grub-core/disk/lvm.c
@@ -140,9 +140,11 @@ grub_lvm_detect (grub_disk_t disk,
grub_err_t err;
grub_uint64_t mda_offset, mda_size;
grub_size_t ptr;
+ grub_uint64_t mda_raw_offset, mda_raw_size;
char buf[GRUB_LVM_LABEL_SIZE];
char vg_id[GRUB_LVM_ID_STRLEN+1];
char pv_id[GRUB_LVM_ID_STRLEN+1];
+ char mdah_buf[sizeof (struct grub_lvm_mda_header) + sizeof (struct
grub_lvm_raw_locn)];
char *metadatabuf, *mda_end, *vgname;
const char *p, *q;
struct grub_lvm_label_header *lh = (struct grub_lvm_label_header *) buf;
@@ -220,21 +222,15 @@ grub_lvm_detect (grub_disk_t disk,
dlocn++;
mda_offset = grub_le_to_cpu64 (dlocn->offset);
- mda_size = grub_le_to_cpu64 (dlocn->size);
/* It's possible to have multiple copies of metadata areas, we just use the
first one. */
-
- /* Allocate buffer space for the circular worst-case scenario. */
- metadatabuf = grub_calloc (2, mda_size);
- if (! metadatabuf)
+ err = grub_disk_read (disk, 0, mda_offset, sizeof (mdah_buf), mdah_buf);
+ if (err)
goto fail;
- err = grub_disk_read (disk, 0, mda_offset, mda_size, metadatabuf);
- if (err)
-goto fail2;
+ mdah = (struct grub_lvm_mda_header *) mdah_buf;
- mdah = (struct grub_lvm_mda_header *) metadatabuf;
if ((grub_strncmp ((char *)mdah->magic, GRUB_LVM_FMTT_MAGIC,
sizeof (mdah->magic)))
|| (grub_le_to_cpu32 (mdah->version) != GRUB_LVM_FMTT_VERSION))
@@ -244,42 +240,58 @@ grub_lvm_detect (grub_disk_t disk,
#ifdef GRUB_UTIL
grub_util_info ("unknown LVM metadata header");
#endif
- goto fail2;
+ goto fail;
}
rlocn = mdah->raw_locns;
- if (grub_le_to_cpu64 (rlocn->offset) >= grub_le_to_cpu64 (mda_size))
+
+ mda_size = grub_le_to_cpu64 (mdah->size);
+ mda_raw_size = grub_le_to_cpu64 (rlocn->size);
+ mda_raw_offset = grub_le_to_cpu64 (rlocn->offset);
+
+ if (mda_raw_offset >= mda_size)
{
#ifdef GRUB_UTIL
grub_util_info ("metadata offset is beyond end of metadata area");
#endif
- goto fail2;
+ goto fail;
}
- if (grub_le_to_cpu64 (rlocn->offset) + grub_le_to_cpu64 (rlocn->size) >
- grub_le_to_cpu64 (mdah->size))
+ metadatabuf = grub_malloc (mda_raw_size);
+
+ if (! metadatabuf)
+goto fail;
+
+ if (mda_raw_offset + mda_raw_size > mda_size)
{
- if (2 * mda_size < GRUB_LVM_MDA_HEADER_SIZE ||
- (grub_le_to_cpu64 (rlocn->offset) + grub_le_to_cpu64 (rlocn->size) -
- grub_le_to_cpu64 (mdah->size) > mda_size - GRUB_LVM_MDA_HEADER_SIZE))
- {
-#ifdef GRUB_UTIL
- grub_util_info ("cannot copy metadata wrap in circular buffer");
-#endif
- goto fail2;
- }
+ err = grub_disk_read (disk, 0,
+ mda_offset + mda_raw_offset,
+ mda_size - mda_raw_offset,
+ metadatabuf);
+ if (err)
+ goto fail2;
/* Metadata is circular. Copy the wrap in place. */
- grub_memcpy (metadatabuf + mda_size,
- metadatabuf + GRUB_LVM_MDA_HEADER_SIZE,
- grub_le_to_cpu64 (rlocn->offset) +
- grub_le_to_cpu64 (rlocn->size) -
- grub_le_to_cpu64 (mdah->size));
+ err = grub_disk_read (disk, 0,
+ mda_offset + GRUB_LVM_MDA_HEADER_SIZE,
+ mda_raw_offset + mda_raw_size - mda_size,
+ metadatabuf + mda_size - mda_raw_offset);
+ if (err)
+ goto fail2;
+}
+ else
+{
+ err = grub_disk_read (disk, 0,
+ mda_offset + mda_raw_offset,
+ mda_raw_size,
+ metadatabuf);
+ if (err)
+ goto fail2;
}
- if (grub_add ((grub_size_t)metadatabuf,
- (grub_size_t)grub_le_to_cpu64 (rlocn->offset),
- &ptr))
+ p = q = metadatabuf;
+
+ if (grub_add ((grub_size_t)metadatabuf, (grub_size_t)mda_raw_size, &ptr))
{
error_parsing_metadata:
#ifdef GRUB_UTIL
@@ -288,11 +300,6 @@ grub_lvm_detect (grub_disk_t disk,
goto fail2;
}
- p = q = (char *)ptr;
-
- i
Re: [PATCH] ofnet: Remove 200 ms timeout in get_card_packet to reduce input latency
Hi, A gentle ping. With many patches posted these days, I hope this one is not overlooked. A quick note: This fixes a one second latency for each text input in the grub interactive shell/editor when the image is net booted, as reported on mkvterm on powerhmc, caused quite a few complaints from our internal lab and QA. Thanks, Michael On Mon, May 06, 2024 at 10:34:22AM GMT, Michael Chang wrote: > When grub image is netbooted on ppc64le, the keyboard input exhibits > significant latency, reports even say that characters are processed > about once per second. This issue makes interactively trying to debug a > ppc64le config very difficult. > > It seems that the latency is largely caused by a 200 ms timeout in the > idle event loop, during which the network card interface is consistently > polled for incoming packets. Often, no packets arrive during this > period, so the timeout nearly always expires, which blocks the response > to key inputs. > > Furthermore, this 200 ms timeout might not need to be enforced at this > basic layer, considering that grub performs synchronous reads and its > timeout management is actually handled by higher layers, not directly in > the card instance. Additionally, the idle polling, which reacts to > unsolicited packets like ICMP and SLAAC, would be fine at a less > frequent polling interval, rather than needing a timeout for receiving a > response. > > For these reasons, we believe the timeout in get_card_packet should be > effectively removed. According to test results, the delay has > disappeared, and it is now much easier to use interactively. > > Signed-Off-by: Michael Chang > Tested-by: Tony Jones > --- > grub-core/net/drivers/ieee1275/ofnet.c | 8 ++-- > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/grub-core/net/drivers/ieee1275/ofnet.c > b/grub-core/net/drivers/ieee1275/ofnet.c > index 78f03df8e..3bf48b3f0 100644 > --- a/grub-core/net/drivers/ieee1275/ofnet.c > +++ b/grub-core/net/drivers/ieee1275/ofnet.c > @@ -82,15 +82,11 @@ get_card_packet (struct grub_net_card *dev) >grub_ssize_t actual; >int rc; >struct grub_ofnetcard_data *data = dev->data; > - grub_uint64_t start_time; >struct grub_net_buff *nb; > > - start_time = grub_get_time_ms (); > - do > -rc = grub_ieee1275_read (data->handle, dev->rcvbuf, dev->rcvbufsize, > &actual); > - while ((actual <= 0 || rc < 0) && (grub_get_time_ms () - start_time < > 200)); > + rc = grub_ieee1275_read (data->handle, dev->rcvbuf, dev->rcvbufsize, > &actual); > > - if (actual <= 0) > + if (actual <= 0 || rc < 0) > return NULL; > >nb = grub_netbuff_alloc (actual + 2); > -- > 2.44.0 > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] lvm: Grub2 fails to detect LVM volumes due to an incorrect computation of mda_end
On Thu, May 16, 2024 at 12:04:21PM GMT, Michael Chang wrote: > On Wed, May 08, 2024 at 05:48:15PM GMT, Daniel Kiper via Grub-devel wrote: > > Adding Marta... > > > > On Mon, May 06, 2024 at 03:18:45PM -0500, Glenn Washburn wrote: > > > From: Rogier > > > > > > When handling a regular LVM volume, Grub can fail with the message: > > > error: disk `lvmid/**------ > > > /**------**' not found. > > > > > > If the condition which triggers this exists, grub-probe will report the > > > error mentioned above. Similarly, the grub boot code will fail to detect > > > LVM volumes, resulting in a failure to boot off of LVM disks/partitions. > > > The condition can be created on any LVM VG by an LVM configuration change, > > > so any system with /boot on LVM can become unbootable at 'any' time (after > > > any LVM configuration change). > > > > > > The problem is caused by an incorrect computation of mda_end in lvm.c, > > > when > > > the metadata area wraps around. Apparently, this can start happening at > > > around 220 metadata changes to the VG. > > The number of times to commit a wrap actually depends on the size of the > metadata area, how many LVs and VGs are connected to the PV and > whichever would take part in the size of active raw metadata block > within the area. > > I managed to use the attached shell script to prepare a LVM disk where > the metadata area is in wrapped state. It took about 100 cycles for me. Hm. In each cycle, two changes (lvcreate/lvremove) are committed. Combined with the initial 30 LVs commit, the total is very close to your 220 metadata changes. Thanks, Michael > With that, I could see the error occurred, and with the patch, the > problem is gone. > > So, Feel free to add my: > > Tested-By: Michael Chang > > Thanks, > Michael > > > > > > > Fixes: 879c4a834 (lvm: Fix two more potential data-dependent alloc > > > overflows) > > > Fixes: https://savannah.gnu.org/bugs/?61620 > > > > > > Signed-off-by: Rogier > > > Signed-off-by: Glenn Washburn > > > > Reviewed-by: Daniel Kiper > > > > Marta, may I ask you to test this patch? > > > > > --- > > > I have done no testing of this patch. I've only created a suitable patch > > > for review. This seems like a fairly serious issue that might one day bite > > > me, so I think it deserves a review. > > > > > > Glenn > > > --- > > > grub-core/disk/lvm.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/grub-core/disk/lvm.c b/grub-core/disk/lvm.c > > > index 794248540cd3..8535d5a5863a 100644 > > > --- a/grub-core/disk/lvm.c > > > +++ b/grub-core/disk/lvm.c > > > @@ -290,7 +290,7 @@ grub_lvm_detect (grub_disk_t disk, > > > > > >p = q = (char *)ptr; > > > > > > - if (grub_add ((grub_size_t)metadatabuf, (grub_size_t)mda_size, &ptr)) > > > + if (grub_add (ptr, (grub_size_t)grub_le_to_cpu64 (rlocn->size), &ptr)) > > > goto error_parsing_metadata; > > > > > >mda_end = (char *)ptr; > > > > Daniel > > > > ___ > > Grub-devel mailing list > > Grub-devel@gnu.org > > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] lvm: Grub2 fails to detect LVM volumes due to an incorrect computation of mda_end
On Wed, May 08, 2024 at 05:48:15PM GMT, Daniel Kiper via Grub-devel wrote: > Adding Marta... > > On Mon, May 06, 2024 at 03:18:45PM -0500, Glenn Washburn wrote: > > From: Rogier > > > > When handling a regular LVM volume, Grub can fail with the message: > > error: disk `lvmid/**------ > > /**------**' not found. > > > > If the condition which triggers this exists, grub-probe will report the > > error mentioned above. Similarly, the grub boot code will fail to detect > > LVM volumes, resulting in a failure to boot off of LVM disks/partitions. > > The condition can be created on any LVM VG by an LVM configuration change, > > so any system with /boot on LVM can become unbootable at 'any' time (after > > any LVM configuration change). > > > > The problem is caused by an incorrect computation of mda_end in lvm.c, when > > the metadata area wraps around. Apparently, this can start happening at > > around 220 metadata changes to the VG. The number of times to commit a wrap actually depends on the size of the metadata area, how many LVs and VGs are connected to the PV and whichever would take part in the size of active raw metadata block within the area. I managed to use the attached shell script to prepare a LVM disk where the metadata area is in wrapped state. It took about 100 cycles for me. With that, I could see the error occurred, and with the patch, the problem is gone. So, Feel free to add my: Tested-By: Michael Chang Thanks, Michael > > > > Fixes: 879c4a834 (lvm: Fix two more potential data-dependent alloc > > overflows) > > Fixes: https://savannah.gnu.org/bugs/?61620 > > > > Signed-off-by: Rogier > > Signed-off-by: Glenn Washburn > > Reviewed-by: Daniel Kiper > > Marta, may I ask you to test this patch? > > > --- > > I have done no testing of this patch. I've only created a suitable patch > > for review. This seems like a fairly serious issue that might one day bite > > me, so I think it deserves a review. > > > > Glenn > > --- > > grub-core/disk/lvm.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/grub-core/disk/lvm.c b/grub-core/disk/lvm.c > > index 794248540cd3..8535d5a5863a 100644 > > --- a/grub-core/disk/lvm.c > > +++ b/grub-core/disk/lvm.c > > @@ -290,7 +290,7 @@ grub_lvm_detect (grub_disk_t disk, > > > >p = q = (char *)ptr; > > > > - if (grub_add ((grub_size_t)metadatabuf, (grub_size_t)mda_size, &ptr)) > > + if (grub_add (ptr, (grub_size_t)grub_le_to_cpu64 (rlocn->size), &ptr)) > > goto error_parsing_metadata; > > > >mda_end = (char *)ptr; > > Daniel > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel lvm-mda-wrap.sh Description: Bourne shell script ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v0 0/2] Secure Boot Advanced Targeting (SBAT) support on powerpc
On Wed, Apr 17, 2024 at 01:27:02AM GMT, Sudhakar Kuppusamy wrote: > This patch set contains the v0 for Secure Boot Advanced Targeting (SBAT) > support on powerpc secure boot. Hi Sudhakar, This patch series cannot be applied to the upstream master because the prerequisites patch series for powerpc secure boot support have not been merged. You should probably consider adding sbat to the powerpc secure boot patches and repost here for review. Thanks, Michael > > In powerpc, PE format Binary are not supported and can't use shim > (https://github.com/rhboot/shim/blob/main/SBAT.md). > However, ELF binary are supported. So, we created new ELF note for SBAT in > ELF binary which store the SBAT data and > SBAT verifier will be there in firmware to read SBAT data from ELF note and > validate it. > > this patch series consists of 2 parts: > > 1) Patch 1: create new ELF Note for SBAT > > we add a new ELF note for SBAT which store the SBAT data. > The name field of shall be the string "Secure-Boot-Advanced-Targeting", > zero-padded > to 4 byte alignment. The type field shall be 0x41536967 (the ASCII values > for the string "sbat"). > > 2) Patch 2: adding sbat data into sbat ELF Note > > it reads the SBAT data from sbat.csv and create the ELF Note for it then > store the SBAT data on it while generate image with -s option > > Sudhakar Kuppusamy and Daniel Axtens (2): > mkimage: create new ELF Note for SBAT > mkimage: adding sbat data into sbat ELF Note on powerpc > > include/grub/util/mkimage.h | 4 +-- > util/grub-mkimagexx.c | 61 ++--- > util/mkimage.c | 21 ++--- > 3 files changed, 74 insertions(+), 12 deletions(-) > > -- > 2.39.3 > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] ofnet: Remove 200 ms timeout in get_card_packet to reduce input latency
When grub image is netbooted on ppc64le, the keyboard input exhibits significant latency, reports even say that characters are processed about once per second. This issue makes interactively trying to debug a ppc64le config very difficult. It seems that the latency is largely caused by a 200 ms timeout in the idle event loop, during which the network card interface is consistently polled for incoming packets. Often, no packets arrive during this period, so the timeout nearly always expires, which blocks the response to key inputs. Furthermore, this 200 ms timeout might not need to be enforced at this basic layer, considering that grub performs synchronous reads and its timeout management is actually handled by higher layers, not directly in the card instance. Additionally, the idle polling, which reacts to unsolicited packets like ICMP and SLAAC, would be fine at a less frequent polling interval, rather than needing a timeout for receiving a response. For these reasons, we believe the timeout in get_card_packet should be effectively removed. According to test results, the delay has disappeared, and it is now much easier to use interactively. Signed-Off-by: Michael Chang Tested-by: Tony Jones --- grub-core/net/drivers/ieee1275/ofnet.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/grub-core/net/drivers/ieee1275/ofnet.c b/grub-core/net/drivers/ieee1275/ofnet.c index 78f03df8e..3bf48b3f0 100644 --- a/grub-core/net/drivers/ieee1275/ofnet.c +++ b/grub-core/net/drivers/ieee1275/ofnet.c @@ -82,15 +82,11 @@ get_card_packet (struct grub_net_card *dev) grub_ssize_t actual; int rc; struct grub_ofnetcard_data *data = dev->data; - grub_uint64_t start_time; struct grub_net_buff *nb; - start_time = grub_get_time_ms (); - do -rc = grub_ieee1275_read (data->handle, dev->rcvbuf, dev->rcvbufsize, &actual); - while ((actual <= 0 || rc < 0) && (grub_get_time_ms () - start_time < 200)); + rc = grub_ieee1275_read (data->handle, dev->rcvbuf, dev->rcvbufsize, &actual); - if (actual <= 0) + if (actual <= 0 || rc < 0) return NULL; nb = grub_netbuff_alloc (actual + 2); -- 2.44.0 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Re: Re: [PATCH] disk: Prioritize OS disk devices over memdisk and procfs
On Mon, Mar 18, 2024 at 12:34:37PM +0100, Daniel Kiper wrote: > On Mon, Mar 18, 2024 at 02:21:36PM +0800, Michael Chang wrote: > > On Fri, Mar 15, 2024 at 04:09:02PM +0100, Daniel Kiper wrote: > > > On Fri, Mar 15, 2024 at 05:00:28PM +0800, Michael Chang via Grub-devel > > > wrote: > > > > Refine iteration to prioritize returning system disk devices over > > > > memdisk and procfs. This adjustment brings about a modest improvement in > > > > search efficiency, particularly during file or UUID-based > > > > searches for a root file system. Additionally, it helps mitigate > > > > potential collisions in file-based searches where memdisk may mistakenly > > > > take precedence over system disks. > > > > > > It seems to me you could do this without adding additional loops. If it > > > is not possible the change begs for comment. > > > > Thanks for review. The added loop for proc and memdisk in the final > > output is required for the `ls' to output list of all devices. I'll add > > this to the comment and send v2 patch. > > I understand that. However, by adding two ifs and two variables or so > you would be able to avoid two additional loops. And I would really > prefer that... The intention behind using two loops is to facilitate two separate rounds of disk pull. The first round specifically targets system disks, helping to exclude undesired factors such as memdisk or procfs in between totally. In my opinion, this sequential approach appears to offer advantages over a single loop where all disk types are mixed together in one type of pull. Thanks, Michael > > Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Re: [PATCH] disk: Prioritize OS disk devices over memdisk and procfs
On Fri, Mar 15, 2024 at 04:09:02PM +0100, Daniel Kiper wrote: > On Fri, Mar 15, 2024 at 05:00:28PM +0800, Michael Chang via Grub-devel wrote: > > Refine iteration to prioritize returning system disk devices over > > memdisk and procfs. This adjustment brings about a modest improvement in > > search efficiency, particularly during file or UUID-based > > searches for a root file system. Additionally, it helps mitigate > > potential collisions in file-based searches where memdisk may mistakenly > > take precedence over system disks. > > It seems to me you could do this without adding additional loops. If it > is not possible the change begs for comment. Thanks for review. The added loop for proc and memdisk in the final output is required for the `ls' to output list of all devices. I'll add this to the comment and send v2 patch. Thanks, Michael > > Daniel > > > Signed-off-by: Michael Chang > > --- > > include/grub/disk.h | 7 ++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/include/grub/disk.h b/include/grub/disk.h > > index fbf23df7f..b3e4f1c8b 100644 > > --- a/include/grub/disk.h > > +++ b/include/grub/disk.h > > @@ -242,7 +242,12 @@ grub_disk_dev_iterate (grub_disk_dev_iterate_hook_t > > hook, void *hook_data) > > > >for (pull = 0; pull < GRUB_DISK_PULL_MAX; pull++) > > for (p = grub_disk_dev_list; p; p = p->next) > > - if (p->disk_iterate && (p->disk_iterate) (hook, hook_data, pull)) > > + if ((p->id != GRUB_DISK_DEVICE_MEMDISK_ID && p->id != > > GRUB_DISK_DEVICE_PROCFS_ID) && p->disk_iterate && (p->disk_iterate) (hook, > > hook_data, pull)) > > + return 1; > > + > > + for (pull = 0; pull < GRUB_DISK_PULL_MAX; pull++) > > +for (p = grub_disk_dev_list; p; p = p->next) > > + if ((p->id == GRUB_DISK_DEVICE_MEMDISK_ID || p->id == > > GRUB_DISK_DEVICE_PROCFS_ID) && p->disk_iterate && (p->disk_iterate) (hook, > > hook_data, pull)) > > return 1; > > > >return 0; ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] disk: Prioritize OS disk devices over memdisk and procfs
Refine iteration to prioritize returning system disk devices over memdisk and procfs. This adjustment brings about a modest improvement in search efficiency, particularly during file or UUID-based searches for a root file system. Additionally, it helps mitigate potential collisions in file-based searches where memdisk may mistakenly take precedence over system disks. Signed-off-by: Michael Chang --- include/grub/disk.h | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/include/grub/disk.h b/include/grub/disk.h index fbf23df7f..b3e4f1c8b 100644 --- a/include/grub/disk.h +++ b/include/grub/disk.h @@ -242,7 +242,12 @@ grub_disk_dev_iterate (grub_disk_dev_iterate_hook_t hook, void *hook_data) for (pull = 0; pull < GRUB_DISK_PULL_MAX; pull++) for (p = grub_disk_dev_list; p; p = p->next) - if (p->disk_iterate && (p->disk_iterate) (hook, hook_data, pull)) + if ((p->id != GRUB_DISK_DEVICE_MEMDISK_ID && p->id != GRUB_DISK_DEVICE_PROCFS_ID) && p->disk_iterate && (p->disk_iterate) (hook, hook_data, pull)) + return 1; + + for (pull = 0; pull < GRUB_DISK_PULL_MAX; pull++) +for (p = grub_disk_dev_list; p; p = p->next) + if ((p->id == GRUB_DISK_DEVICE_MEMDISK_ID || p->id == GRUB_DISK_DEVICE_PROCFS_ID) && p->disk_iterate && (p->disk_iterate) (hook, hook_data, pull)) return 1; return 0; -- 2.44.0 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/6] ieee1275/powerpc: enables device mapper discovery
On Mon, May 08, 2023 at 01:58:36PM +, Avnish Chouhan wrote:
> From: Diego Domingos
>
> This patch enables the device mapper discovery on ofpath.c. Currently,
> when we are dealing with a device like /dev/dm-* the ofpath returns null
> since there is no function implemented to handle this case.
>
> This patch implements a function that will look into /sys/block/dm-*
> devices and search recursively inside slaves directory to find the root
> disk.
>
> Signed-off-by: Diego Domingos
> ---
> grub-core/osdep/linux/ofpath.c | 64 +-
> 1 file changed, 63 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/osdep/linux/ofpath.c b/grub-core/osdep/linux/ofpath.c
> index 0f5d54e9f2d..cc849d9c94c 100644
> --- a/grub-core/osdep/linux/ofpath.c
> +++ b/grub-core/osdep/linux/ofpath.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
>
> #ifdef __sparc__
> typedef enum
> @@ -755,13 +756,74 @@ strip_trailing_digits (const char *p)
> return new;
> }
>
> +static char *
> +get_slave_from_dm(const char * device){
> + char *curr_device, *tmp;
> + char *directory;
> + char *ret = NULL;
> +
> + directory = grub_strdup (device);
> + tmp = get_basename(directory);
> + curr_device = grub_strdup (tmp);
> + *tmp = '\0';
> +
> + /* Recursively check for slaves devices so we can find the root device */
> + while ((curr_device[0] == 'd') && (curr_device[1] == 'm') &&
> (curr_device[2] == '-')){
> +DIR *dp;
> +struct dirent *ep;
> +char* device_path;
> +
> +device_path = grub_xasprintf ("/sys/block/%s/slaves", curr_device);
> +dp = opendir(device_path);
> +free(device_path);
> +
> +if (dp != NULL)
> + {
> +ep = readdir (dp);
> +while (ep != NULL)
> + {
> + /* avoid some system directories */
> +if (!strcmp(ep->d_name,"."))
> + goto next_dir;
> +if (!strcmp(ep->d_name,".."))
> + goto next_dir;
> +
> + free (curr_device);
> + free (ret);
> + curr_device = grub_strdup (ep->d_name);
> + ret = grub_xasprintf ("%s%s", directory, curr_device);
> + break;
> +
> +next_dir:
> +ep = readdir (dp);
> +continue;
> + }
> +closedir (dp);
> + }
> +else
> + grub_util_warn (_("cannot open directory `%s'"), device_path);
This will lead to UAF (Use After Free) for the device_path pointer.
Thanks,
Micahel
> + }
> +
> + free (directory);
> + free (curr_device);
> +
> + return ret;
> +}
> +
> char *
> grub_util_devname_to_ofpath (const char *sys_devname)
> {
> - char *name_buf, *device, *devnode, *devicenode, *ofpath;
> + char *name_buf, *device, *devnode, *devicenode, *ofpath, *realname;
>
> name_buf = xrealpath (sys_devname);
>
> + realname = get_slave_from_dm (name_buf);
> + if (realname)
> +{
> + free (name_buf);
> + name_buf = realname;
> +}
> +
> device = get_basename (name_buf);
> devnode = strip_trailing_digits (name_buf);
> devicenode = strip_trailing_digits (device);
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 7/7] verifiers: Verify after decompression
On Wed, Mar 13, 2024 at 03:07:48PM +, Ross Lagerwall via Grub-devel wrote:
> It is convenient and common to have binaries stored in gzip archives
> (e.g. xen.gz). Verification should be run after decompression rather
> than before so reorder the file filter list as appropriate.
The proposed change would result in the disruption of the tpm and pgp
clients within the verifier framework. Specifically, the tpm pcr
prediction software relies on the integrity of raw files rather than
decompressed ones. Additionally, pgp detached signatures are designed to
target original files, thus necessitating the current structure to
maintain functionality.
Thanks,
Michael
>
> Signed-off-by: Ross Lagerwall
> ---
> include/grub/file.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/grub/file.h b/include/grub/file.h
> index a5bf3a792d6f..a1ef3582bc7b 100644
> --- a/include/grub/file.h
> +++ b/include/grub/file.h
> @@ -182,10 +182,10 @@ extern grub_disk_read_hook_t
> EXPORT_VAR(grub_file_progress_hook);
> /* Filters with lower ID are executed first. */
> typedef enum grub_file_filter_id
>{
> -GRUB_FILE_FILTER_VERIFY,
> GRUB_FILE_FILTER_GZIO,
> GRUB_FILE_FILTER_XZIO,
> GRUB_FILE_FILTER_LZOPIO,
> +GRUB_FILE_FILTER_VERIFY,
> GRUB_FILE_FILTER_MAX,
> GRUB_FILE_FILTER_COMPRESSION_FIRST = GRUB_FILE_FILTER_GZIO,
> GRUB_FILE_FILTER_COMPRESSION_LAST = GRUB_FILE_FILTER_LZOPIO,
> --
> 2.43.0
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] gfxmenu: resolve false grub_errno disrupting boot process
When enabling gfxmenu and choosing to boot the Xen hypervisor from its menu, an error occurred: "error: ../../grub-core/video/bitmap_scale.c:42:null src bitmap in grub_video_create_scaled." The error is returned by grub_video_bitmap_create_scaled() when the source pixmap is not there. The init_background() uses it to scale up the background image so it can fully fit into the screen resolution. However not all backgrounds are set by a image, ie the "desktop-image" property of the theme file. Instead a color code may be used, for example openSUSE's green background uses "desktop-color" property: desktop-color: "#0D202F" So it is absolutely fine to call init_background() without a raw pixmap if color code is used. A missing check has to be added to ensure the grub_errno will not be erroneously set and gets in the way of ensuing boot process. The reason it happens sporadically is due to grub_errno is reset to GRUB_ERR_NONE in other places if a function's error return can be ignored. In particular this hunk in grub_gfxmenu_create_box() does the majority of the reset of grub_errno returned by init_background(), but the path may not be always chosen. grub_video_bitmap_load (&box->raw_pixmaps[i], path); grub_free (path); /* Ignore missing pixmaps. */ grub_errno = GRUB_ERR_NONE; In any case, we cannot account on such random behavior and should only return grub_errno if it is justified. Signed-off-by: Michael Chang --- grub-core/gfxmenu/view.c | 5 + 1 file changed, 5 insertions(+) diff --git a/grub-core/gfxmenu/view.c b/grub-core/gfxmenu/view.c index 6358004b2..8ed3fd1e6 100644 --- a/grub-core/gfxmenu/view.c +++ b/grub-core/gfxmenu/view.c @@ -556,6 +556,11 @@ init_background (grub_gfxmenu_view_t view) if (view->scaled_desktop_image) return; + /* You don't have to scale a raw image if it's not present; this prevents + * setting grub_errno and disrupting a command's execution. */ + if (view->raw_desktop_image == NULL) +return; + struct grub_video_bitmap *scaled_bitmap; if (view->desktop_image_scale_method == GRUB_VIDEO_BITMAP_SELECTION_METHOD_STRETCH) -- 2.43.0 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH V5] ieee1275/ofdisk: retry on open and read failure
On Wed, Jan 24, 2024 at 11:42:30AM +0530, Mukesh Kumar Chaurasiya wrote:
> Sometimes, when booting from a very busy SAN, the access to the
> disk can fail and then GRUB will eventually drop to GRUB prompt.
> This scenario is more frequent when deploying many machines at
> the same time using the same SAN.
> This patch aims to force the ofdisk module to retry the open or
> read function for network disks excluding after it fails. We use
> DEFAULT_RETRY_TIMEOUT, which is 15 seconds to specify the time it'll
> retry to access the disk before it definitely fails. The timeout can be
> changed by setting the environment variable ofdisk_retry_timeout.
> If the environment variable fails to read, GRUB will consider the
> default value of 15 seconds.
>
> Signed-off-by: Diego Domingos
> Signed-off-by: Mukesh Kumar Chaurasiya
> ---
> docs/grub.texi | 8 +++
> grub-core/disk/ieee1275/ofdisk.c | 91 ++--
> 2 files changed, 96 insertions(+), 3 deletions(-)
>
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 975e521d1..db0acb869 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -3306,6 +3306,7 @@ These variables have special meaning to GRUB.
> * net_default_ip::
> * net_default_mac::
> * net_default_server::
> +* ofdisk_retry_timeout::
> * pager::
> * prefix::
> * pxe_blksize::
> @@ -3728,6 +3729,13 @@ The default is the value of @samp{color_normal}
> (@pxref{color_normal}).
> @xref{Network}.
>
>
> +@node ofdisk_retry_timeout
> +@subsection ofdisk_retry_timeout
> +
> +The time in seconds till which the GRUB will retry to open or read a disk in
> +case of failure to do so. This value defaults to 15 seconds.
> +
> +
> @node pager
> @subsection pager
>
> diff --git a/grub-core/disk/ieee1275/ofdisk.c
> b/grub-core/disk/ieee1275/ofdisk.c
> index c6cba0c8a..d90b9b70b 100644
> --- a/grub-core/disk/ieee1275/ofdisk.c
> +++ b/grub-core/disk/ieee1275/ofdisk.c
> @@ -24,6 +24,9 @@
> #include
> #include
> #include
> +#include
> +
> +#define RETRY_DEFAULT_TIMEOUT 15
>
> static char *last_devpath;
> static grub_ieee1275_ihandle_t last_ihandle;
> @@ -452,7 +455,7 @@ compute_dev_path (const char *name)
> }
>
> static grub_err_t
> -grub_ofdisk_open (const char *name, grub_disk_t disk)
> +grub_ofdisk_open_real (const char *name, grub_disk_t disk)
> {
>grub_ieee1275_phandle_t dev;
>char *devpath;
> @@ -525,6 +528,61 @@ grub_ofdisk_open (const char *name, grub_disk_t disk)
>return 0;
> }
>
> +static grub_uint64_t
> +grub_ofdisk_disk_timeout (grub_disk_t disk)
> +{
> + grub_uint64_t retry = RETRY_DEFAULT_TIMEOUT;
> + const char *timeout = grub_env_get ("ofdisk_retry_timeout");
> + const char *timeout_end;
> +
> + if (grub_strstr (disk->name, "fibre-channel") != NULL ||
> + grub_strstr (disk->name, "vfc-client") != NULL)
Is there a reason why nvme-of now exempted from the retrying ? It was
tested in v4 like this:
+ if (!(grub_strstr (disk->name, "fibre-channel@") ||
+ grub_strstr (disk->name, "vfc-client")) ||
+ grub_strstr(disk->name, "nvme-of"))
+{
+ /* Do not retry in case of non network drives */
+ return 0;
+}
Thanks,
Michael
> +{
> + if (timeout == NULL)
> +{
> + return retry;
> +}
> + retry = grub_strtoul (timeout, &timeout_end, 10);
> + /* Ignore all errors and return default timeout */
> + if (grub_errno != GRUB_ERR_NONE ||
> + *timeout == '\0' ||
> + *timeout_end != '\0')
> +{
> + return RETRY_DEFAULT_TIMEOUT;
> +}
> +}
> + else
> +return 0;
> +
> + return retry;
> +}
> +
> +static grub_err_t
> +grub_ofdisk_open (const char *name, grub_disk_t disk)
> +{
> + grub_err_t err;
> + grub_uint64_t timeout = grub_get_time_ms () + (grub_ofdisk_disk_timeout
> (disk) * 1000);
> + grub_uint16_t inc = 0;
> +
> + do
> +{
> + err = grub_ofdisk_open_real (name, disk);
> + if (err == GRUB_ERR_UNKNOWN_DEVICE)
> +{
> + grub_dprintf ("ofdisk", "Failed to open disk %s.\n", name);
> +}
> + if (grub_get_time_ms () >= timeout)
> +break;
> + grub_dprintf ("ofdisk", "Retry to open disk %s.\n", name);
> + /*
> + * Increase in wait time for subsequent requests
> + * Cur time is used as a random number here
> + */
> + grub_millisleep ((32 << ++inc) * (grub_get_time_ms () % 32));
> +} while (1);
> + return err;
> +}
> +
> static void
> grub_ofdisk_close (grub_disk_t disk)
> {
> @@ -568,8 +626,8 @@ grub_ofdisk_prepare (grub_disk_t disk, grub_disk_addr_t
> sector)
> }
>
> static grub_err_t
> -grub_ofdisk_read (grub_disk_t disk, grub_disk_addr_t sector,
> - grub_size_t size, char *buf)
> +grub_ofdisk_read_real (grub_disk_t disk, grub_disk_addr_t sector,
> + grub_size_t size, char *buf)
> {
>grub_err_t err;
>grub_ssize_t actual;
> @@ -587,6 +645,33 @@ grub_ofdisk_read (g
Re: grub shell: unkown commands alwasy exit with zero code
On Fri, Jan 12, 2024 at 05:58:02PM +0100, Itxaka serrano wrote: > Hey all, > > I opened a bug because this behaviour doesnt seem correct to me: > > https://savannah.gnu.org/bugs/?65154 > > > Example: > > grub> hello > error: ../../grub-core/script/function.c:119:can't find command `hello'. > grub> echo $? > 0 > > > Kind of weird because on the code it seems like its returning a > GRUB_ERR_UNKNOWN_COMMAND which should not be zero. I had a quick look and > maybe its becuase on line 1018 of grub-core/script/execute.c we print the > error but always return 0 > https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/script/execute.c#n1018 > > Is this expected behaviour or is it a mistake and we should not only print > the error but return the actual error? The behavior is expected: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=bc028f2f86. Given the limited context, it remains unclear if the rationale behind this change can be easily retraced today. My take is that this modification may have been implemented to support the continued functionality of older `grub.cfg` files, even after certain commands have been removed. This ensures compatibility with the latest version of GRUB. Alternatively, it seems reasonable to halt execution when encountering a missing command, considering the potential consequence of such situations. Thanks, Michael > > Cheers, > Itxaka > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Improving grub-mkstandalone for reproducible build
Enclosed is the description from openSUSE bugzilla entry: While working on reproducible builds for openSUSE, I found that our grub2 package's /usr/share/grub2/x86_64-xen/grub.xen varies across builds. I identified 2 issues: The tar contains changing (octal) mtime values. The tar stores files in random filesystem readdir order. The first issue produces such diffs: --- old /usr/share/grub2/x86_64-xen/grub.xen (objdump) +++ new /usr/share/grub2/x86_64-xen/grub.xen (objdump) @@ -4896,7 +4896,7 @@ 01319f 30303030 36303000 30303031 600.0001 0131af 37353000 30303031 37353000 30303030 750.0001750. 0131bf 30303033 34353000 31343533 31323035 0003450.14531205 - 0131cf 35303300 30303135 30313320 3000 503.0015013 0... + 0131cf 36313200 30303135 30313420 3000 612.0015014 0... 0131df 0131ef and the second issue produced this diff: 01311f 0100 01312f 0100 08b42600 ..&. 01313f 626f6f74 2f677275 622f7838 365f3634 boot/grub/x86_64 - 01314f 2d78656e 2f646973 6b2e6d6f 6400 -xen/disk.mod... + 01314f 2d78656e 2f6c7378 656e2e6d 6f64 -xen/lsxen.mod.. 01315f The second issue probably comes from grub_util_fd_readdir that would need to collect+sort entries before further processing. Furthermore, both patches were developed to address the aforementioned issues individually. We hope to contribute them to upstream if the enhancement sounds appealing to others as well. Thanks. Michael Chang (2): mkstandalone: ensure stable timestamps for generated images mkstandalone: ensure deterministic tar file creation by sorting contents util/grub-mkstandalone.c | 36 1 file changed, 28 insertions(+), 8 deletions(-) -- 2.43.0 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 2/2] mkstandalone: ensure deterministic tar file creation by sorting contents
The add_tar_files() function currently iterates through a directory's
content using readdir(), which doesn't guarantee a specific order. This
lack of deterministic behavior impacts reproducibility in the build
process.
This commit resolves the issue by introducing sorting functionality. The
list retrieved by readdir() is now sorted alphabetically before
incorporation into the tar archive, ensuring consistent and predictable
file ordering within the archive.
Signed-off-by: Michael Chang
Signed-off-by: Bernhard Wiedemann
---
util/grub-mkstandalone.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/util/grub-mkstandalone.c b/util/grub-mkstandalone.c
index 8e1229925..e4b5bcab4 100644
--- a/util/grub-mkstandalone.c
+++ b/util/grub-mkstandalone.c
@@ -205,22 +205,42 @@ add_tar_file (const char *from,
{
grub_util_fd_dir_t d;
grub_util_fd_dirent_t de;
+ char **from_files;
+ grub_size_t alloc = 8, used = 0;
+ grub_size_t i;
d = grub_util_fd_opendir (from);
+ from_files = xmalloc (alloc * sizeof (*from_files));
while ((de = grub_util_fd_readdir (d)))
{
- char *fp, *tfp;
if (strcmp (de->d_name, ".") == 0)
continue;
if (strcmp (de->d_name, "..") == 0)
continue;
- fp = grub_util_path_concat (2, from, de->d_name);
- tfp = xasprintf ("%s/%s", to, de->d_name);
+ if (alloc <= used)
+ {
+ alloc <<= 1;
+ from_files = xrealloc (from_files, alloc * sizeof (*from_files));
+ }
+ from_files[used++] = xstrdup(de->d_name);
+ }
+ qsort (from_files, used, sizeof (*from_files), grub_qsort_strcmp);
+
+ for (i = 0; i < used; i++)
+ {
+ char *fp, *tfp;
+
+ fp = grub_util_path_concat (2, from, from_files[i]);
+ tfp = xasprintf ("%s/%s", to, from_files[i]);
add_tar_file (fp, tfp);
+ free (tfp);
free (fp);
+ free (from_files[i]);
}
+
grub_util_fd_closedir (d);
+ free (from_files);
free (tcn);
return;
}
--
2.43.0
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 1/2] mkstandalone: ensure stable timestamps for generated images
This change mirrors a previous fix [1] but is specific to images generated by grub-mkstandalone. The former fix (85a7be241) focused on utilizing a stable timestamp during binary generation in the util/mkimage context. This commit extends that approach to the images produced by grub-mkstandalone, ensuring consistency and stability in timestamps across all generated binaries. [1] 85a7be241 util/mkimage: Use stable timestamp when generating binaries. Signed-off-by: Michael Chang Signed-off-by: Bernhard Wiedemann --- util/grub-mkstandalone.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/util/grub-mkstandalone.c b/util/grub-mkstandalone.c index bdbeea6a6..8e1229925 100644 --- a/util/grub-mkstandalone.c +++ b/util/grub-mkstandalone.c @@ -30,6 +30,9 @@ #pragma GCC diagnostic error "-Wmissing-prototypes" #pragma GCC diagnostic error "-Wmissing-declarations" +/* use 2015-01-01T00:00:00+ as a stock timestamp */ +#define STABLE_EMBEDDING_TIMESTAMP 1420070400 + static char *output_image; static char **files; static int nfiles; @@ -184,7 +187,6 @@ add_tar_file (const char *from, struct head hd; grub_util_fd_t in; ssize_t r; - grub_uint32_t mtime = 0; grub_uint32_t size; COMPILE_TIME_ASSERT (sizeof (hd) == 512); @@ -192,8 +194,6 @@ add_tar_file (const char *from, if (grub_util_is_special_file (from)) return; - mtime = grub_util_get_mtime (from); - optr = tcn = xmalloc (strlen (to) + 1); for (iptr = to; *iptr == '/'; iptr++); for (; *iptr; iptr++) @@ -234,7 +234,7 @@ add_tar_file (const char *from, memcpy (hd.gid, "0001750", 7); set_tar_value (hd.size, optr - tcn, 12); - set_tar_value (hd.mtime, mtime, 12); + set_tar_value (hd.mtime, STABLE_EMBEDDING_TIMESTAMP, 12); hd.typeflag = 'L'; memcpy (hd.magic, MAGIC, sizeof (hd.magic)); memcpy (hd.uname, "grub", 4); @@ -264,7 +264,7 @@ add_tar_file (const char *from, memcpy (hd.gid, "0001750", 7); set_tar_value (hd.size, size, 12); - set_tar_value (hd.mtime, mtime, 12); + set_tar_value (hd.mtime, STABLE_EMBEDDING_TIMESTAMP, 12); hd.typeflag = '0'; memcpy (hd.magic, MAGIC, sizeof (hd.magic)); memcpy (hd.uname, "grub", 4); -- 2.43.0 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] acpi: skip NULL entries in RSDT and XSDT
During attempts to configure a serial console, a Page Fault Exception
and system reset were encountered, specifically on release 2.12-rc1.
This issue was not present in prior versions and seemed to affect only a
specific machine, potentially pointing to hardware or firmware flaw.
After investigation, it was discovered that the invalid page access
occurred during the discovery of serial MMIO ports as specified by
ACPI's SPCR table [1]. The recent change uncovered an issue in Grub's
ACPI driver.
In certain cases, the XSDT/RSDT root table might contain a null entry as
a terminator, depending on how the tables are assembled. Grub cannot
blindly trust the address in the root table to be valid and should
perform a sanity check for null entries. This patch introduces this
simple check.
This fix is also inspired by a related Linux kernel fix [2]:
[1] 7b192ec4c term/ns8250: Use ACPI SPCR table when available to configure
serial
[2] 0f929fbf0 ACPICA: Tables: Add new mechanism to skip NULL entries in RSDT
and XSDT.
Signed-off-by: Michael Chang
---
grub-core/kern/acpi.c | 8
1 file changed, 8 insertions(+)
diff --git a/grub-core/kern/acpi.c b/grub-core/kern/acpi.c
index c61115dcd..1d1faa0dc 100644
--- a/grub-core/kern/acpi.c
+++ b/grub-core/kern/acpi.c
@@ -51,6 +51,10 @@ grub_acpi_rsdt_find_table (struct grub_acpi_table_header
*rsdt, const char *sig)
for (; s; s--, ptr++)
{
struct grub_acpi_table_header *tbl;
+
+ /* Skip NULL entries in RSDT/XSDT */
+ if (!ptr->val)
+ continue;
tbl = (struct grub_acpi_table_header *) (grub_addr_t) ptr->val;
if (grub_memcmp (tbl->signature, sig, 4) == 0)
return tbl;
@@ -75,6 +79,10 @@ grub_acpi_xsdt_find_table (struct grub_acpi_table_header
*xsdt, const char *sig)
for (; s; s--, ptr++)
{
struct grub_acpi_table_header *tbl;
+
+ /* Skip NULL entries in RSDT/XSDT */
+ if (!ptr->val)
+ continue;
#if GRUB_CPU_SIZEOF_VOID_P != 8
if (ptr->val >> 32)
continue;
--
2.42.0
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: regression in cryptomount -u
On Thu, Aug 17, 2023 at 10:52:58AM +0200, Olaf Hering wrote:
> Prior commit 3cf2e848bc03 ("disk/cryptodisk: Allows UUIDs to be compared
> in a dash-insensitive manner") the grub.cfg below worked as expected:
> create a menu, which if selected tries to open the specified partition
> and does further processing. In case the passphrase was wrong, it would
> just return and offer the menu again.
>
> With the commit above, the specified partition is opened, but cryptomount
> returns an error. As a result no further processing is done, the menu is
> shown again. It needs to be selected once more to do the actual processing.
I have ran into the error as well. As a side note the error message
looked like:
Enter passphrase for hd1,gpt3 (471eff62-ee8a-4b69-b449-031dd5449198):
Attempting to decrypt master key...
Slot 0 opened
error: ../../grub-core/disk/cryptodisk.c:1512:no such cryptodisk found,
perhaps a needed disk or
cryptodisk module is not loaded.
For me the disk unlocked and continued without problem despite the error.
Thanks,
Michael
>
> This change works for me:
>
> --- a/grub-core/disk/cryptodisk.c
> +++ b/grub-core/disk/cryptodisk.c
> @@ -1236,7 +1236,7 @@ grub_cryptodisk_scan_device (const char *name,
>dev = grub_cryptodisk_scan_device_real (name, source, cargs);
>if (dev)
> {
> - ret = (cargs->search_uuid != NULL && grub_strcasecmp
> (cargs->search_uuid, dev->uuid) == 0);
> + ret = cargs->search_uuid && !grub_uuidcasecmp(cargs->search_uuid,
> dev->uuid, sizeof(dev->uuid));
>goto cleanup;
> }
>
>
>
> submenu x {
> insmod luks
> if cryptomount -u ${uuid_without_dashes} ; then
> do_work
> fi
> }
>
>
> Olaf
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ieee1275/ofdisk: retry on open and read failure
On Tue, Mar 28, 2023 at 11:00:01AM +0530, Mukesh Kumar Chaurasiya wrote:
> Sometimes, when booting from a very busy SAN, the access to the
> disk can fail and then grub will eventually drop to grub prompt.
> This scenario is more frequent when deploying many machines at
> the same time using the same SAN.
> This patch aims to force the ofdisk module to retry the open or
> read function after it fails. We use MAX_RETRIES to specify the
> amount of times it will try to access the disk before it
> definitely fails.
To clarify this is a continuation of previous patch [1]. Obviously the
count of retries, MAX_RETRIES, has been replaced by a timeout,
RETRY_DEFAULT_TIMEOUT, which is 15000 milliseconds or fifteen seconds.
It appears that the description was not updated accordingly and needs to
be amended.
[1] https://www.mail-archive.com/grub-devel@gnu.org/msg32174.html
Thanks,
Michael
>
> Signed-off-by: Mukesh Kumar Chaurasiya
> ---
> grub-core/disk/ieee1275/ofdisk.c | 65 +++-
> 1 file changed, 63 insertions(+), 2 deletions(-)
>
> diff --git a/grub-core/disk/ieee1275/ofdisk.c
> b/grub-core/disk/ieee1275/ofdisk.c
> index c6cba0c8a..f4183a531 100644
> --- a/grub-core/disk/ieee1275/ofdisk.c
> +++ b/grub-core/disk/ieee1275/ofdisk.c
> @@ -24,6 +24,9 @@
> #include
> #include
> #include
> +#include
> +
> +#define RETRY_DEFAULT_TIMEOUT 15000
>
> static char *last_devpath;
> static grub_ieee1275_ihandle_t last_ihandle;
> @@ -452,7 +455,7 @@ compute_dev_path (const char *name)
> }
>
> static grub_err_t
> -grub_ofdisk_open (const char *name, grub_disk_t disk)
> +grub_ofdisk_open_real (const char *name, grub_disk_t disk)
> {
>grub_ieee1275_phandle_t dev;
>char *devpath;
> @@ -525,6 +528,41 @@ grub_ofdisk_open (const char *name, grub_disk_t disk)
>return 0;
> }
>
> +static grub_uint64_t
> +grub_ofdisk_disk_timeout(void)
> +{
> + if(grub_env_get("ofdisk_retry_timeout") != NULL)
> + {
> + grub_uint64_t retry =
> grub_strtoul(grub_env_get("ofdisk_retry_timeout"), 0, 10);
> + if(retry)
> + return retry;
> + }
> +
> + return RETRY_DEFAULT_TIMEOUT;
> +}
> +
> +static grub_err_t
> +grub_ofdisk_open (const char *name, grub_disk_t disk)
> +{
> + grub_err_t err;
> + grub_uint64_t timeout = grub_get_time_ms () + grub_ofdisk_disk_timeout();
> +
> + retry:
> + err = grub_ofdisk_open_real (name, disk);
> +
> + if (err == GRUB_ERR_UNKNOWN_DEVICE)
> +{
> + if (grub_get_time_ms () < timeout)
> +{
> + grub_dprintf ("ofdisk","Failed to open disk %s. Retrying...\n",
> name);
> + grub_errno = GRUB_ERR_NONE;
> + goto retry;
> + }
> +}
> +
> + return err;
> +}
> +
> static void
> grub_ofdisk_close (grub_disk_t disk)
> {
> @@ -568,7 +606,7 @@ grub_ofdisk_prepare (grub_disk_t disk, grub_disk_addr_t
> sector)
> }
>
> static grub_err_t
> -grub_ofdisk_read (grub_disk_t disk, grub_disk_addr_t sector,
> +grub_ofdisk_read_real (grub_disk_t disk, grub_disk_addr_t sector,
> grub_size_t size, char *buf)
> {
>grub_err_t err;
> @@ -587,6 +625,29 @@ grub_ofdisk_read (grub_disk_t disk, grub_disk_addr_t
> sector,
>return 0;
> }
>
> +static grub_err_t
> +grub_ofdisk_read (grub_disk_t disk, grub_disk_addr_t sector,
> + grub_size_t size, char *buf)
> +{
> + grub_err_t err;
> + grub_uint64_t timeout = grub_get_time_ms () + grub_ofdisk_disk_timeout();
> +
> + retry:
> + err = grub_ofdisk_read_real (disk, sector, size, buf);
> +
> + if (err == GRUB_ERR_READ_ERROR)
> +{
> + if (grub_get_time_ms () < timeout)
> +{
> + grub_dprintf ("ofdisk","Failed to read disk %s. Retrying...\n",
> (char*)disk->data);
> + grub_errno = GRUB_ERR_NONE;
> + goto retry;
> + }
> +}
> +
> + return err;
> +}
> +
> static grub_err_t
> grub_ofdisk_write (grub_disk_t disk, grub_disk_addr_t sector,
> grub_size_t size, const char *buf)
> --
> 2.31.1
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v4] tpm: Disable tpm verifier if tpm is not present
On Tue, Mar 21, 2023 at 03:35:33PM +0100, Daniel Kiper wrote: > On Mon, Mar 20, 2023 at 06:18:26PM +0800, Michael Chang via Grub-devel wrote: > > When the TPM module is loaded, the verifier reads the entire file into > > memory, measures and extends the hash, and uses the verified content as > > a backing buffer for disk files. However, this process can result in a > > high memory utilization cost per file operation, sometimes causing the > > system to run out of memory, which can lead to boot failure. To address > > this issue, previous patches have optimized memory management by > > I would mention at least commit 887f98f0d (mm: Allow dynamically > requesting additional memory regions) here. OK. I will do it. > > > dynamically allocating heap space to maximize memory usage and reduce > > the threat of memory exhaustion. But in some cases, problems may still > > arise, such as when large ISO images are mounted using loopback or when > > dealing with embedded systems with limited memory resources. > > > > Unfortunately, the current implementation of the TPM module doesn't > > allow for the elimination of the back buffer once it is loaded, even if > > no TPM device is present or the device has been explicitly disabled. > > This can lead to wasted memory. To solve this issue, a patch has been > > developed to detect the TPM status at the time of loading and skip > > verifier registration if the device is missing or deactivated. This > > prevents the allocation of memory for a back buffer, avoiding wasted > > memory when no real measure boot functionality is performed. This patch > > also provides users with the option to disable the TPM device to free up > > memory in scenarios where the system can't afford the high memory > > utilization cost. > > The last sentence is confusing because it gives an impression the patch > adds an option to the GRUB to "disable the TPM device". Which of course > is not true. I expect you wanted to say something like that: "disabling > the TPM device in the system reduces memory usage in the GRUB. This can > be useful in scenarios where the system can't afford the high memory > utilization cost and nobody cares about the measurements of loaded > artifacts." Initially, I want to emphasize that after this proposed change, disabling TPM will become an option to free up memory for others. However, my previous expression may have been confusing, and I apologize for that. Thank you for your review, and I have updated the v5 patch to address your comment. Regards, Michael > > Otherwise patch LGTM... > > Daniel > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v5] tpm: Disable tpm verifier if tpm is not present
When the TPM module is loaded, the verifier reads the entire file into
memory, measures and extends the hash, and uses the verified content as
a backing buffer for disk files. However, this process can result in a
high memory utilization cost per file operation, sometimes causing the
system to run out of memory, which can lead to boot failure. To address
this issue, commit 887f98f0d (mm: Allow dynamically requesting
additional memory regions), have optimized memory management by
dynamically allocating heap space to maximize memory usage and reduce
the threat of memory exhaustion. But in some cases, problems may still
arise, such as when large ISO images are mounted using loopback or when
dealing with embedded systems with limited memory resources.
Unfortunately, the current implementation of the TPM module doesn't
allow for the elimination of the back buffer once it is loaded, even if
no TPM device is present or the device has been explicitly disabled.
This can lead to wasted memory. To solve this issue, a patch has been
developed to detect the TPM status at the time of loading and skip
verifier registration if the device is missing or deactivated. This
prevents the allocation of memory for a back buffer, avoiding wasted
memory when no real measure boot functionality is performed. Disabling
the TPM device in the system can reduce memory usage in grub, which is
useful in scenarios where high memory utilization is a concern and
measurements of loaded artifacts are not necessary.
Signed-off-by: Michael Chang
Signed-off-by: Stefan Berger
---
grub-core/commands/efi/tpm.c | 37 +++
grub-core/commands/ieee1275/ibmvtpm.c | 20 +++
grub-core/commands/tpm.c | 11
include/grub/tpm.h| 1 +
4 files changed, 59 insertions(+), 10 deletions(-)
diff --git a/grub-core/commands/efi/tpm.c b/grub-core/commands/efi/tpm.c
index ae09c1bf8..e1f343fea 100644
--- a/grub-core/commands/efi/tpm.c
+++ b/grub-core/commands/efi/tpm.c
@@ -287,3 +287,40 @@ grub_tpm_measure (unsigned char *buf, grub_size_t size,
grub_uint8_t pcr,
else
return grub_tpm2_log_event (tpm_handle, buf, size, pcr, description);
}
+
+int
+grub_tpm_present (void)
+{
+ grub_efi_handle_t tpm_handle;
+ grub_efi_uint8_t protocol_version;
+
+ if (!grub_tpm_handle_find (&tpm_handle, &protocol_version))
+return 0;
+
+ if (protocol_version == 1)
+{
+ grub_efi_tpm_protocol_t *tpm;
+
+ tpm = grub_efi_open_protocol (tpm_handle, &tpm_guid,
+ GRUB_EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+ if (!tpm)
+ {
+ grub_dprintf ("tpm", "Cannot open TPM protocol\n");
+ return 0;
+ }
+ return grub_tpm1_present (tpm);
+}
+ else
+{
+ grub_efi_tpm2_protocol_t *tpm;
+
+ tpm = grub_efi_open_protocol (tpm_handle, &tpm2_guid,
+ GRUB_EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+ if (!tpm)
+ {
+ grub_dprintf ("tpm", "Cannot open TPM protocol\n");
+ return 0;
+ }
+ return grub_tpm2_present (tpm);
+}
+}
diff --git a/grub-core/commands/ieee1275/ibmvtpm.c
b/grub-core/commands/ieee1275/ibmvtpm.c
index 239942d27..e01759c17 100644
--- a/grub-core/commands/ieee1275/ibmvtpm.c
+++ b/grub-core/commands/ieee1275/ibmvtpm.c
@@ -135,16 +135,6 @@ grub_err_t
grub_tpm_measure (unsigned char *buf, grub_size_t size, grub_uint8_t pcr,
const char *description)
{
- /*
- * Call tpm_init() 'late' rather than from GRUB_MOD_INIT() so that device
nodes
- * can be found.
- */
- grub_err_t err = tpm_init ();
-
- /* Absence of a TPM isn't a failure. */
- if (err != GRUB_ERR_NONE)
-return GRUB_ERR_NONE;
-
grub_dprintf ("tpm", "log_event, pcr = %d, size = 0x%" PRIxGRUB_SIZE ",
%s\n",
pcr, size, description);
@@ -153,3 +143,13 @@ grub_tpm_measure (unsigned char *buf, grub_size_t size,
grub_uint8_t pcr,
return GRUB_ERR_NONE;
}
+
+int
+grub_tpm_present (void)
+{
+ /*
+ * Call tpm_init() 'late' rather than from GRUB_MOD_INIT() so that device
nodes
+ * can be found.
+ */
+ return tpm_init() == GRUB_ERR_NONE;
+}
diff --git a/grub-core/commands/tpm.c b/grub-core/commands/tpm.c
index 3437e8e03..3128bede0 100644
--- a/grub-core/commands/tpm.c
+++ b/grub-core/commands/tpm.c
@@ -103,10 +103,21 @@ struct grub_file_verifier grub_tpm_verifier = {
GRUB_MOD_INIT (tpm)
{
+ /*
+ * Even though this now calls ibmvtpm's grub_tpm_present() from
+ * GRUB_MOD_INIT(), it does seem to call it late enough in the initialization
+ * sequence so that whatever discovered 'device nodes' before this
+ * GRUB_MOD_INIT() is called, enables the ibmvtpm driver to see the device
+ * nodes.
+ */
+ if (!grub_tpm_present())
+return;
grub_verifier_register (&grub_tpm_verifier);
}
GRUB_MOD_FINI (tpm)
{
+ if (!grub_tpm_present())
+return;
grub_verifier_unregister (&grub_tpm_verifier);
}
diff --git
[PATCH v4] tpm: Disable tpm verifier if tpm is not present
When the TPM module is loaded, the verifier reads the entire file into
memory, measures and extends the hash, and uses the verified content as
a backing buffer for disk files. However, this process can result in a
high memory utilization cost per file operation, sometimes causing the
system to run out of memory, which can lead to boot failure. To address
this issue, previous patches have optimized memory management by
dynamically allocating heap space to maximize memory usage and reduce
the threat of memory exhaustion. But in some cases, problems may still
arise, such as when large ISO images are mounted using loopback or when
dealing with embedded systems with limited memory resources.
Unfortunately, the current implementation of the TPM module doesn't
allow for the elimination of the back buffer once it is loaded, even if
no TPM device is present or the device has been explicitly disabled.
This can lead to wasted memory. To solve this issue, a patch has been
developed to detect the TPM status at the time of loading and skip
verifier registration if the device is missing or deactivated. This
prevents the allocation of memory for a back buffer, avoiding wasted
memory when no real measure boot functionality is performed. This patch
also provides users with the option to disable the TPM device to free up
memory in scenarios where the system can't afford the high memory
utilization cost.
Signed-off-by: Michael Chang
Signed-off-by: Stefan Berger
---
grub-core/commands/efi/tpm.c | 37 +++
grub-core/commands/ieee1275/ibmvtpm.c | 20 +++
grub-core/commands/tpm.c | 11
include/grub/tpm.h| 1 +
4 files changed, 59 insertions(+), 10 deletions(-)
diff --git a/grub-core/commands/efi/tpm.c b/grub-core/commands/efi/tpm.c
index ae09c1bf8..e1f343fea 100644
--- a/grub-core/commands/efi/tpm.c
+++ b/grub-core/commands/efi/tpm.c
@@ -287,3 +287,40 @@ grub_tpm_measure (unsigned char *buf, grub_size_t size,
grub_uint8_t pcr,
else
return grub_tpm2_log_event (tpm_handle, buf, size, pcr, description);
}
+
+int
+grub_tpm_present (void)
+{
+ grub_efi_handle_t tpm_handle;
+ grub_efi_uint8_t protocol_version;
+
+ if (!grub_tpm_handle_find (&tpm_handle, &protocol_version))
+return 0;
+
+ if (protocol_version == 1)
+{
+ grub_efi_tpm_protocol_t *tpm;
+
+ tpm = grub_efi_open_protocol (tpm_handle, &tpm_guid,
+ GRUB_EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+ if (!tpm)
+ {
+ grub_dprintf ("tpm", "Cannot open TPM protocol\n");
+ return 0;
+ }
+ return grub_tpm1_present (tpm);
+}
+ else
+{
+ grub_efi_tpm2_protocol_t *tpm;
+
+ tpm = grub_efi_open_protocol (tpm_handle, &tpm2_guid,
+ GRUB_EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+ if (!tpm)
+ {
+ grub_dprintf ("tpm", "Cannot open TPM protocol\n");
+ return 0;
+ }
+ return grub_tpm2_present (tpm);
+}
+}
diff --git a/grub-core/commands/ieee1275/ibmvtpm.c
b/grub-core/commands/ieee1275/ibmvtpm.c
index 239942d27..e01759c17 100644
--- a/grub-core/commands/ieee1275/ibmvtpm.c
+++ b/grub-core/commands/ieee1275/ibmvtpm.c
@@ -135,16 +135,6 @@ grub_err_t
grub_tpm_measure (unsigned char *buf, grub_size_t size, grub_uint8_t pcr,
const char *description)
{
- /*
- * Call tpm_init() 'late' rather than from GRUB_MOD_INIT() so that device
nodes
- * can be found.
- */
- grub_err_t err = tpm_init ();
-
- /* Absence of a TPM isn't a failure. */
- if (err != GRUB_ERR_NONE)
-return GRUB_ERR_NONE;
-
grub_dprintf ("tpm", "log_event, pcr = %d, size = 0x%" PRIxGRUB_SIZE ",
%s\n",
pcr, size, description);
@@ -153,3 +143,13 @@ grub_tpm_measure (unsigned char *buf, grub_size_t size,
grub_uint8_t pcr,
return GRUB_ERR_NONE;
}
+
+int
+grub_tpm_present (void)
+{
+ /*
+ * Call tpm_init() 'late' rather than from GRUB_MOD_INIT() so that device
nodes
+ * can be found.
+ */
+ return tpm_init() == GRUB_ERR_NONE;
+}
diff --git a/grub-core/commands/tpm.c b/grub-core/commands/tpm.c
index 3437e8e03..3128bede0 100644
--- a/grub-core/commands/tpm.c
+++ b/grub-core/commands/tpm.c
@@ -103,10 +103,21 @@ struct grub_file_verifier grub_tpm_verifier = {
GRUB_MOD_INIT (tpm)
{
+ /*
+ * Even though this now calls ibmvtpm's grub_tpm_present() from
+ * GRUB_MOD_INIT(), it does seem to call it late enough in the initialization
+ * sequence so that whatever discovered 'device nodes' before this
+ * GRUB_MOD_INIT() is called, enables the ibmvtpm driver to see the device
+ * nodes.
+ */
+ if (!grub_tpm_present())
+return;
grub_verifier_register (&grub_tpm_verifier);
}
GRUB_MOD_FINI (tpm)
{
+ if (!grub_tpm_present())
+return;
grub_verifier_unregister (&grub_tpm_verifier);
}
diff --git a/include/grub/tpm.h b/include/grub/tpm.h
index 5c285cbc5..c19fcbd0a 100644
--- a/include/gru
Re: [PATCH v3] tpm: Disable tpm verifier if tpm is not present
On Mon, Mar 13, 2023 at 02:29:41PM +0100, Daniel Kiper wrote: > On Mon, Feb 20, 2023 at 02:36:18PM +0800, Michael Chang via Grub-devel wrote: > > This helps to prevent out of memory error when reading large files via > > disabling tpm device as verifier has to read all content into memory in > > one chunk to measure the hash and extend to tpm. > > > > For ibmvtpm driver support this change here would be needed. It helps to > > prevent much memory consuming tpm subsystem from being activated when no > > vtpm device present. > > I have taken a look at this patch once again with fresh mind. Now I think > the main advantage of having it is that we do not load files twice when > there is lack of TPM and there are no other verifiers present. Though it It is *at least* twice the cost of memory for any opened file until it is closed. > is difficult to get it from the current commit message. So, I think it > has to be changed in the following way: > - the problem description, > - how the problem is solved by this patch and what are the other > advantages of having it in the GRUB, > - how the problem is mitigated by the recent mm changes on the > platforms with TPM enabled. Thanks for your time on review the patch. I will try to come up with better description according to your comment in next revision. Regards, Michael > > Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: strange grub error on ARM64
On Fri, Mar 10, 2023 at 01:15:40PM +0800, Michael Chang via Grub-devel wrote: > On Thu, Mar 09, 2023 at 02:10:54AM -0800, Atish Patra wrote: > > On Mon, Mar 6, 2023 at 7:21 PM Michael Chang wrote: [snip] > > I have a small favor to ask. Is it possible for you to test out the > > changes[1] on the ARM64 platform ? > > Sure. I'll do it next week and come back to you for any result. It all worked well for me until secure boot was enabled and MOK was used to verify the kernel image. Here is the error message: error: ../../grub-core/loader/efi/linux.c:203:cannot load image. Loading Linux 5.14.21-150400.24.46-default ... Loading initial ramdisk ... Press any key to continue... [Security] 3rd party image[0] can be loaded after EndOfDxe: MemoryMapped(0x2,0x75754000,0x77A36200). DxeImageVerificationLib: Image is signed but signature is not allowed by DB and SHA256 hash of image is not found in DB/DBX. The image doesn't pass verification: MemoryMapped(0x2,0x75754000,0x77A36200) It is not a problem in the patch itself, but the LoadImage based approach hardly to work with MOK since the UEFI firmware doesn't recognize key stores other than the standard KEK and DB of type authvar. Thanks, Michael ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: strange grub error on ARM64
On Thu, Mar 09, 2023 at 02:10:54AM -0800, Atish Patra wrote:
> On Mon, Mar 6, 2023 at 7:21 PM Michael Chang wrote:
> >
> > On Mon, Mar 06, 2023 at 04:22:53PM -0800, Atish Patra wrote:
> > > On Mon, Mar 6, 2023 at 1:25 PM Fabian Vogt wrote:
> > > >
> > > > Hi,
> > > >
> > > > Am Montag, 6. März 2023, 21:59:23 CET schrieb Daniel Kiper:
> > > > > Adding Gary and Michael...
> > > > >
> > > > > Gary, Michael, could you help with this? Or at least forward this
> > > > > email
> > > > > to folks who may help...
> > > > >
> > > > > Daniel
> > > > >
> > > > > On Mon, Mar 06, 2023 at 10:56:52AM -0800, Atish Patra wrote:
> > > > > > Hi,
> > > > > > I am working on a cross-architecture cleanup series that removes the
> > > > > > arch specific headers from RISC-V, ARM, ARM64 and unifies the linux
> > > > > > loader on ARM64 & Linux.
> > > > > >
> > > > > > The v7 version can be found here.
> > > > > > https://lists.gnu.org/archive/html/grub-devel/2023-02/msg00046.html
> > > > > >
> > > > > > It had a few bugs which are fixed and can be found here.
> > > > > >
> > > > > > Here are the patches
> > > > > > https://github.com/atishp04/grub/commits/riscv_uefi_v8
> > > > > >
> > > > > > Anybody with ARM64 and/or test setup: Can you please do a quick test
> > > > > > to see if you see similar or any other failure ?
> > > > > >
> > > > > > I noticed a very strange error during ARM64 testing. I have probably
> > > > > > done something stupid during the grub build
> > > > > > as I can reproduce this with upstream grub as well.
> > > > > >
> > > > > > I was trying to boot an OpenSuse image in qemu virt machine for
> > > > > > ARM64 as per
> > > > > > the instructions[1]. The stock grub image works fine however my
> > > > > > custom
> > > > > > build fails to boot
> > > > > > and drops to the grub command line. It seems the grub detects the
> > > > > > disk
> > > > > > but doesn't read the root partition correctly on my cross-compiled
> > > > > > image.
> > > > > > It has one additional directory ("@") which I don't see when I mount
> > > > > > the disk. it doesn't list any files as well.
> > > >
> > > > What you see is the expected behaviour with upstream GRUB.
> > > > The btrfs volume contains various subvolumes below @ which are mounted
> > > > into the
> > > > root file system at various points. The root filesystem itself is at
> > > > @/.snapshots//snapshot/ and set as the default subvolume.
> > > > That's what
> > > > is mounted in a running system if you pass default flags. To see the
> > > > same as
> > > > GRUB, you can do mount -o subvolume=/ /dev/foo3 /mnt.
> > > >
> > >
> > > Thanks!! Thank god I am not crazy as I thought I was ;)
> > >
> > > > Downstream there's a patch (and multiple related ones) that makes GRUB
> > > > mount
> > > > the default subvolume instead of the root of the filesystem:
> > > > https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/grub2-btrfs-03-follow_default.patch?expand=1&rev=285
> > > >
> > >
> > > Is this the only patch or I need to pull all the patches on that tree
> > > to make it work ?
> >
> > You'll need other patch so that files not in default subvolume can be
> > accessed through mount at grub's runtime, also to enable automatic setup
> > via the utility grub-(install|mkconfig).
> >
> > >
> > > Is there an easy way to test upstream grub stuff on ARM64 in case I
> > > need to pull more dependent patches to make it work?
> >
> > You can also use rpm from this Open Build Service (OBS) project:
> >
> > https://build.opensuse.org/package/show/home:michael-chang:grub:devel/grub2
> >
> > It is for merging upstream git with SUSE patches rebased regularly per
> > month convenient to catch early build failure, find regression, try out
> > new feature and so on.
> >
>
> Thanks for pointing that out. But it seems all the patches are on top
> of some older release of grub.
> I am trying to test patches on top of the upstream and some of these
> patches may not apply cleanly.
>
> I was looking for alternatives with other distros. But every other
> distro probably carries a similar number
> of out-of-tree patches.
The downstream patch may jump to PE entry point directly for verified
image buffer given UEFI LoadImage() will return security violation for
verified signatures by the key only exist in Machine Owner Key (MOK)
keyring.
> Here is the fedora one.
>
> https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/grub.patches
>
> I have a small favor to ask. Is it possible for you to test out the
> changes[1] on the ARM64 platform ?
Sure. I'll do it next week and come back to you for any result.
> You probably have to rebase suse patches on top of upstream first as
> well. But you would probably do it much much much faster than me
> given my limited knowledge about grub & suse.
>
> [1] https://github.com/atishp04/grub/commits/riscv_uefi_v8
The riscv_uefi would have been riscv_arm64_uefi as long as they are
synchronized in this branch. :)
Thanks,
Michael
>
> >
Re: strange grub error on ARM64
On Mon, Mar 06, 2023 at 04:22:53PM -0800, Atish Patra wrote:
> On Mon, Mar 6, 2023 at 1:25 PM Fabian Vogt wrote:
> >
> > Hi,
> >
> > Am Montag, 6. März 2023, 21:59:23 CET schrieb Daniel Kiper:
> > > Adding Gary and Michael...
> > >
> > > Gary, Michael, could you help with this? Or at least forward this email
> > > to folks who may help...
> > >
> > > Daniel
> > >
> > > On Mon, Mar 06, 2023 at 10:56:52AM -0800, Atish Patra wrote:
> > > > Hi,
> > > > I am working on a cross-architecture cleanup series that removes the
> > > > arch specific headers from RISC-V, ARM, ARM64 and unifies the linux
> > > > loader on ARM64 & Linux.
> > > >
> > > > The v7 version can be found here.
> > > > https://lists.gnu.org/archive/html/grub-devel/2023-02/msg00046.html
> > > >
> > > > It had a few bugs which are fixed and can be found here.
> > > >
> > > > Here are the patches
> > > > https://github.com/atishp04/grub/commits/riscv_uefi_v8
> > > >
> > > > Anybody with ARM64 and/or test setup: Can you please do a quick test
> > > > to see if you see similar or any other failure ?
> > > >
> > > > I noticed a very strange error during ARM64 testing. I have probably
> > > > done something stupid during the grub build
> > > > as I can reproduce this with upstream grub as well.
> > > >
> > > > I was trying to boot an OpenSuse image in qemu virt machine for ARM64
> > > > as per
> > > > the instructions[1]. The stock grub image works fine however my custom
> > > > build fails to boot
> > > > and drops to the grub command line. It seems the grub detects the disk
> > > > but doesn't read the root partition correctly on my cross-compiled
> > > > image.
> > > > It has one additional directory ("@") which I don't see when I mount
> > > > the disk. it doesn't list any files as well.
> >
> > What you see is the expected behaviour with upstream GRUB.
> > The btrfs volume contains various subvolumes below @ which are mounted into
> > the
> > root file system at various points. The root filesystem itself is at
> > @/.snapshots//snapshot/ and set as the default subvolume. That's
> > what
> > is mounted in a running system if you pass default flags. To see the same as
> > GRUB, you can do mount -o subvolume=/ /dev/foo3 /mnt.
> >
>
> Thanks!! Thank god I am not crazy as I thought I was ;)
>
> > Downstream there's a patch (and multiple related ones) that makes GRUB mount
> > the default subvolume instead of the root of the filesystem:
> > https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/grub2-btrfs-03-follow_default.patch?expand=1&rev=285
> >
>
> Is this the only patch or I need to pull all the patches on that tree
> to make it work ?
You'll need other patch so that files not in default subvolume can be
accessed through mount at grub's runtime, also to enable automatic setup
via the utility grub-(install|mkconfig).
>
> Is there an easy way to test upstream grub stuff on ARM64 in case I
> need to pull more dependent patches to make it work?
You can also use rpm from this Open Build Service (OBS) project:
https://build.opensuse.org/package/show/home:michael-chang:grub:devel/grub2
It is for merging upstream git with SUSE patches rebased regularly per
month convenient to catch early build failure, find regression, try out
new feature and so on.
Thanks,
Michael
>
> > The design of the "Boot into Snapshot" functionality relies on this.
> >
> > > > = Cross compiled grub image =
> > > > grub> ls -l (hd0,gpt3)/
> > > > DIR 20230302080325 @/
> > > >
> > > > grub> ls -l (hd0,gpt3)/@/
> > > > DIR 20230302080326 boot/
> > > > DIR srv/
> > > > DIR 20230302080326 usr/
> > > > DIR opt/
> > > > DIR 20230302080326 home/
> > > > DIR var/
> > > > DIR tmp/
> > > > DIR root/
> > > >
> > > > grub> ls -l (hd0,gpt3)/@/boot/
> > > > DIR 20230302080326 grub2/
> > > >
> > > > grub>
> > > > = Stock grub image from the OpenSuse
> > > > image=
> > > > grub> ls (hd0,gpt3)/
> > > > dev/ run/ boot/ config.partids lib sbin srv/ usr/ opt/
> > > > config.bootoptions lib64
> > > > .snapshots/ bin home/ etc/ var/ tmp/ sys/ mnt/ proc/ root/
> > > >
> > > > The same build steps works fine for RISC-V for OpenSuse image though.
> > > > However, I couldn't figure out what it was. Any help is appreciated.
> >
> > It's possible that it does not use snapshot or not even btrfs.
> >
> > Cheers,
> > Fabian
> >
> > > > [1] https://en.opensuse.org/openSUSE:AArch64
> > > >
> > > > --
> > > > Regards,
> > > > Atish
> > >
> > > ___
> > > Grub-devel mailing list
> > > Grub-devel@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> >
>
>
> --
> Regards,
> Atish
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] tpm: Disable tpm verifier if tpm is not present
On Fri, Mar 03, 2023 at 07:19:56PM +0100, Daniel Kiper wrote: > On Fri, Mar 03, 2023 at 12:18:19PM +0800, Michael Chang wrote: > > On Thu, Mar 02, 2023 at 07:59:00PM +0100, Daniel Kiper wrote: > > > On Tue, Feb 28, 2023 at 11:22:14AM +0800, Michael Chang via Grub-devel > > > wrote: > > > > On Thu, Feb 23, 2023 at 02:22:27PM +0100, Daniel Kiper wrote: > > > > > Adding James, Stefan and Robbie... > > > > > > > > > > On Mon, Feb 20, 2023 at 12:57:01PM +0800, Michael Chang via > > > > > Grub-devel wrote: > > > > > > On Tue, Nov 29, 2022 at 04:11:48PM +0100, Daniel Kiper wrote: > > > > > > > On Fri, Nov 25, 2022 at 03:00:48PM +0800, Michael Chang via > > > > > > > Grub-devel wrote: > > > > > > > > On Thu, Nov 24, 2022 at 05:04:48PM +0100, Daniel Kiper wrote: > > > > > > > > > On Mon, Oct 17, 2022 at 01:19:08PM +0800, Michael Chang via > > > > > > > > > Grub-devel wrote: > > > > > > > > > > On Fri, Oct 14, 2022 at 11:40:01AM +0200, Daniel Kiper > > > > > > > > > > wrote: > > > > > > > > > > > On Fri, Oct 07, 2022 at 01:37:10PM +0800, Michael Chang > > > > > > > > > > > via Grub-devel wrote: > > > > > > > > > > > > This helps to prevent out of memory error when reading > > > > > > > > > > > > large files via disabling > > > > > > > > > > > > tpm device as verifier has to read all content into > > > > > > > > > > > > memory in one chunk to > > > > > > > > > > > > measure the hash and extend to tpm. > > > > > > > > > > > > > > > > > > > > > > How does this patch help when the TPM is present in the > > > > > > > > > > > system? > > > > > > > > > > > > > > > > > > > > If the firmware menu offers option to disable TPM device, > > > > > > > > > > then this > > > > > > > > > > patch can be useful to get around 'out of memory error' > > > > > > > > > > through > > > > > > > > > > disabling TPM device from firmware in order to make tpm > > > > > > > > > > verifier won't > > > > > > > > > > be in the way of reading huge files. > > > > > > > > > > > > > > > > > > > > This is essentially a compromised solution as long as tpm > > > > > > > > > > module can be > > > > > > > > > > a built-in module in signed image and at the same time user > > > > > > > > > > may come > > > > > > > > > > across the need to open huge files, for eg, loopback mount > > > > > > > > > > in grub for > > > > > > > > > > the rescue image. In this case they could be opted in to > > > > > > > > > > disable tpm > > > > > > > > > > device from firmware to proceed if they run into out of > > > > > > > > > > memory or other > > > > > > > > > > (slow) reading issues. > > > > > > > > > > > > > > > > > > I think I would prefer something similar to this [1] patch. > > > > > > > > > Of course > > > > > > > > > if [1] is not enough... > > > > > > > > > > > > > > > > The tpm verifier attempts to set GRUB_VERIFY_FLAGS_SINGLE_CHUNK > > > > > > > > for all > > > > > > > > incoming files, which gets loaded into memory in its entirety > > > > > > > > as an > > > > > > > > duplicated copy to disk files. The overhead is too huge to some > > > > > > > > low > > > > > > > > profile hardwares with smaller memory or when the boot path has > > > > > > > > to cover > > > > > > > > very large files, hence the out of memory error. > > > > > > > > > > > > > > > > I think it inevitable to use GRUB_VERIFY_FLAGS_SINGLE_CHUNK as > >
Re: [PATCH v2] tpm: Disable tpm verifier if tpm is not present
On Thu, Mar 02, 2023 at 07:59:00PM +0100, Daniel Kiper wrote: > On Tue, Feb 28, 2023 at 11:22:14AM +0800, Michael Chang via Grub-devel wrote: > > On Thu, Feb 23, 2023 at 02:22:27PM +0100, Daniel Kiper wrote: > > > Adding James, Stefan and Robbie... > > > > > > On Mon, Feb 20, 2023 at 12:57:01PM +0800, Michael Chang via Grub-devel > > > wrote: > > > > On Tue, Nov 29, 2022 at 04:11:48PM +0100, Daniel Kiper wrote: > > > > > On Fri, Nov 25, 2022 at 03:00:48PM +0800, Michael Chang via > > > > > Grub-devel wrote: > > > > > > On Thu, Nov 24, 2022 at 05:04:48PM +0100, Daniel Kiper wrote: > > > > > > > On Mon, Oct 17, 2022 at 01:19:08PM +0800, Michael Chang via > > > > > > > Grub-devel wrote: > > > > > > > > On Fri, Oct 14, 2022 at 11:40:01AM +0200, Daniel Kiper wrote: > > > > > > > > > On Fri, Oct 07, 2022 at 01:37:10PM +0800, Michael Chang via > > > > > > > > > Grub-devel wrote: > > > > > > > > > > This helps to prevent out of memory error when reading > > > > > > > > > > large files via disabling > > > > > > > > > > tpm device as verifier has to read all content into memory > > > > > > > > > > in one chunk to > > > > > > > > > > measure the hash and extend to tpm. > > > > > > > > > > > > > > > > > > How does this patch help when the TPM is present in the > > > > > > > > > system? > > > > > > > > > > > > > > > > If the firmware menu offers option to disable TPM device, then > > > > > > > > this > > > > > > > > patch can be useful to get around 'out of memory error' through > > > > > > > > disabling TPM device from firmware in order to make tpm > > > > > > > > verifier won't > > > > > > > > be in the way of reading huge files. > > > > > > > > > > > > > > > > This is essentially a compromised solution as long as tpm > > > > > > > > module can be > > > > > > > > a built-in module in signed image and at the same time user may > > > > > > > > come > > > > > > > > across the need to open huge files, for eg, loopback mount in > > > > > > > > grub for > > > > > > > > the rescue image. In this case they could be opted in to > > > > > > > > disable tpm > > > > > > > > device from firmware to proceed if they run into out of memory > > > > > > > > or other > > > > > > > > (slow) reading issues. > > > > > > > > > > > > > > I think I would prefer something similar to this [1] patch. Of > > > > > > > course > > > > > > > if [1] is not enough... > > > > > > > > > > > > The tpm verifier attempts to set GRUB_VERIFY_FLAGS_SINGLE_CHUNK for > > > > > > all > > > > > > incoming files, which gets loaded into memory in its entirety as an > > > > > > duplicated copy to disk files. The overhead is too huge to some low > > > > > > profile hardwares with smaller memory or when the boot path has to > > > > > > cover > > > > > > very large files, hence the out of memory error. > > > > > > > > > > > > I think it inevitable to use GRUB_VERIFY_FLAGS_SINGLE_CHUNK as tpm > > > > > > measures and extends file intergrity. But we ought to avoid the > > > > > > overhead > > > > > > when TPM device is not present or disabled by the user. > > > > > > > > > > > > The patch [1] seems to deal with the tpm error which prevents a file > > > > > > from being opened, which is orthogonal to the memory allocation > > > > > > issue in > > > > > > the common verifier before tpm doing measurement. > > > > > > > > > > This is what I expected. So, that is why I said "Of course if [1] is > > > > > not > > > > > enough..."... :-) Now I think it would be nice if TPM verifier is > > > > > disabled when the TPM device is broken/disabled/... and/or somebod
[PATCH] devmapper: Fix build error on 32bit host
The gcc build has failed for 32bit host (for eg, i386-emu and arm-emu)
due to mismatch between format specifier and data type.
../grub-core/osdep/devmapper/getroot.c: In function
'grub_util_pull_devmapper':
../grub-core/osdep/devmapper/getroot.c:265:75: error: format '%lu'
expects argument of type 'long unsigned int', but argument 2 has type
'int' [-Werror=format=]
../grub-core/osdep/devmapper/getroot.c:276:80: error: format '%lu'
expects argument of type 'long unsigned int', but argument 2 has type
'int' [-Werror=format=]
This patch fixes the problem by casting the type of calculated offset to
grub_size_t and use platform PRIuGRUB_SIZE as format specifier.
Signed-off-by: Michael Chang
---
grub-core/osdep/devmapper/getroot.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/grub-core/osdep/devmapper/getroot.c
b/grub-core/osdep/devmapper/getroot.c
index cc3f7daff..a9e8784f2 100644
--- a/grub-core/osdep/devmapper/getroot.c
+++ b/grub-core/osdep/devmapper/getroot.c
@@ -262,7 +262,7 @@ grub_util_pull_devmapper (const char *os_dev)
params);
cipher = grub_strndup (c, seek_head - c);
if (cipher == NULL)
-grub_util_error (_("could not strndup cipher of length
`%lu'"), seek_head - c);
+grub_util_error (_("could not strndup cipher of length `%"
PRIuGRUB_SIZE "'"), (grub_size_t)(seek_head - c));
remaining -= seek_head - c + 1;
c = seek_head + 1;
@@ -273,7 +273,7 @@ grub_util_pull_devmapper (const char *os_dev)
params);
cipher_mode = grub_strndup (c, seek_head - c);
if (cipher_mode == NULL)
-grub_util_error (_("could not strndup cipher_mode of length
`%lu'"), seek_head - c);
+grub_util_error (_("could not strndup cipher_mode of length
`%" PRIuGRUB_SIZE "'"), (grub_size_t)(seek_head - c));
remaining -= seek_head - c + 1;
c = seek_head + 1;
--
2.39.2
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] tpm: Disable tpm verifier if tpm is not present
On Thu, Feb 23, 2023 at 02:22:27PM +0100, Daniel Kiper wrote: > Adding James, Stefan and Robbie... > > On Mon, Feb 20, 2023 at 12:57:01PM +0800, Michael Chang via Grub-devel wrote: > > On Tue, Nov 29, 2022 at 04:11:48PM +0100, Daniel Kiper wrote: > > > On Fri, Nov 25, 2022 at 03:00:48PM +0800, Michael Chang via Grub-devel > > > wrote: > > > > On Thu, Nov 24, 2022 at 05:04:48PM +0100, Daniel Kiper wrote: > > > > > On Mon, Oct 17, 2022 at 01:19:08PM +0800, Michael Chang via > > > > > Grub-devel wrote: > > > > > > On Fri, Oct 14, 2022 at 11:40:01AM +0200, Daniel Kiper wrote: > > > > > > > On Fri, Oct 07, 2022 at 01:37:10PM +0800, Michael Chang via > > > > > > > Grub-devel wrote: > > > > > > > > This helps to prevent out of memory error when reading large > > > > > > > > files via disabling > > > > > > > > tpm device as verifier has to read all content into memory in > > > > > > > > one chunk to > > > > > > > > measure the hash and extend to tpm. > > > > > > > > > > > > > > How does this patch help when the TPM is present in the system? > > > > > > > > > > > > If the firmware menu offers option to disable TPM device, then this > > > > > > patch can be useful to get around 'out of memory error' through > > > > > > disabling TPM device from firmware in order to make tpm verifier > > > > > > won't > > > > > > be in the way of reading huge files. > > > > > > > > > > > > This is essentially a compromised solution as long as tpm module > > > > > > can be > > > > > > a built-in module in signed image and at the same time user may come > > > > > > across the need to open huge files, for eg, loopback mount in grub > > > > > > for > > > > > > the rescue image. In this case they could be opted in to disable tpm > > > > > > device from firmware to proceed if they run into out of memory or > > > > > > other > > > > > > (slow) reading issues. > > > > > > > > > > I think I would prefer something similar to this [1] patch. Of course > > > > > if [1] is not enough... > > > > > > > > The tpm verifier attempts to set GRUB_VERIFY_FLAGS_SINGLE_CHUNK for all > > > > incoming files, which gets loaded into memory in its entirety as an > > > > duplicated copy to disk files. The overhead is too huge to some low > > > > profile hardwares with smaller memory or when the boot path has to cover > > > > very large files, hence the out of memory error. > > > > > > > > I think it inevitable to use GRUB_VERIFY_FLAGS_SINGLE_CHUNK as tpm > > > > measures and extends file intergrity. But we ought to avoid the overhead > > > > when TPM device is not present or disabled by the user. > > > > > > > > The patch [1] seems to deal with the tpm error which prevents a file > > > > from being opened, which is orthogonal to the memory allocation issue in > > > > the common verifier before tpm doing measurement. > > > > > > This is what I expected. So, that is why I said "Of course if [1] is not > > > enough..."... :-) Now I think it would be nice if TPM verifier is > > > disabled when the TPM device is broken/disabled/... and/or somebody sets > > > a separate environemnt variable in the GRUB. WDYT? > > > > I'm not sure if a separate environment a good idea, because it would > > expose the funtion to disable verifier in a way much readily accessible > > through one of grub command line interface, grub.cfg and grubenv file so > > that the intention have to be very carefully reviewed here. > > I think it should be safe because even if somebody is doing nasty things > with disabling the TPM verifier they can be easily detected or will lead > to early boot failures when the TPM is used to store secrets. Of course > there is small chance somebody disables the TPM verifier during platform > initialization/installation. However, this should be also easily to > detect due to, e.g., lack of measurements. IMHO it is hardly be detectable, there's no clear distinction to it is a result of lack of measurement or a compromised system if we know that tpm is active and working ... > Anyway, I would extend the > GRUB documentation with a note saying that platform > initialization/installation should happen in well controlled > environment. Just in case... Yes the initial bootstrapping environemt or process is important, but also there's system update which should happen in a well controlled environment as well. Thanks, Michael > > Daniel > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v3] tpm: Disable tpm verifier if tpm is not present
This helps to prevent out of memory error when reading large files via
disabling tpm device as verifier has to read all content into memory in
one chunk to measure the hash and extend to tpm.
For ibmvtpm driver support this change here would be needed. It helps to
prevent much memory consuming tpm subsystem from being activated when no
vtpm device present.
Signed-off-by: Michael Chang
Signed-off-by: Stefan Berger
---
grub-core/commands/efi/tpm.c | 37 +++
grub-core/commands/ieee1275/ibmvtpm.c | 20 +++
grub-core/commands/tpm.c | 11
include/grub/tpm.h| 1 +
4 files changed, 59 insertions(+), 10 deletions(-)
diff --git a/grub-core/commands/efi/tpm.c b/grub-core/commands/efi/tpm.c
index ae09c1bf8..e1f343fea 100644
--- a/grub-core/commands/efi/tpm.c
+++ b/grub-core/commands/efi/tpm.c
@@ -287,3 +287,40 @@ grub_tpm_measure (unsigned char *buf, grub_size_t size,
grub_uint8_t pcr,
else
return grub_tpm2_log_event (tpm_handle, buf, size, pcr, description);
}
+
+int
+grub_tpm_present (void)
+{
+ grub_efi_handle_t tpm_handle;
+ grub_efi_uint8_t protocol_version;
+
+ if (!grub_tpm_handle_find (&tpm_handle, &protocol_version))
+return 0;
+
+ if (protocol_version == 1)
+{
+ grub_efi_tpm_protocol_t *tpm;
+
+ tpm = grub_efi_open_protocol (tpm_handle, &tpm_guid,
+ GRUB_EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+ if (!tpm)
+ {
+ grub_dprintf ("tpm", "Cannot open TPM protocol\n");
+ return 0;
+ }
+ return grub_tpm1_present (tpm);
+}
+ else
+{
+ grub_efi_tpm2_protocol_t *tpm;
+
+ tpm = grub_efi_open_protocol (tpm_handle, &tpm2_guid,
+ GRUB_EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+ if (!tpm)
+ {
+ grub_dprintf ("tpm", "Cannot open TPM protocol\n");
+ return 0;
+ }
+ return grub_tpm2_present (tpm);
+}
+}
diff --git a/grub-core/commands/ieee1275/ibmvtpm.c
b/grub-core/commands/ieee1275/ibmvtpm.c
index 239942d27..e01759c17 100644
--- a/grub-core/commands/ieee1275/ibmvtpm.c
+++ b/grub-core/commands/ieee1275/ibmvtpm.c
@@ -135,16 +135,6 @@ grub_err_t
grub_tpm_measure (unsigned char *buf, grub_size_t size, grub_uint8_t pcr,
const char *description)
{
- /*
- * Call tpm_init() 'late' rather than from GRUB_MOD_INIT() so that device
nodes
- * can be found.
- */
- grub_err_t err = tpm_init ();
-
- /* Absence of a TPM isn't a failure. */
- if (err != GRUB_ERR_NONE)
-return GRUB_ERR_NONE;
-
grub_dprintf ("tpm", "log_event, pcr = %d, size = 0x%" PRIxGRUB_SIZE ",
%s\n",
pcr, size, description);
@@ -153,3 +143,13 @@ grub_tpm_measure (unsigned char *buf, grub_size_t size,
grub_uint8_t pcr,
return GRUB_ERR_NONE;
}
+
+int
+grub_tpm_present (void)
+{
+ /*
+ * Call tpm_init() 'late' rather than from GRUB_MOD_INIT() so that device
nodes
+ * can be found.
+ */
+ return tpm_init() == GRUB_ERR_NONE;
+}
diff --git a/grub-core/commands/tpm.c b/grub-core/commands/tpm.c
index 3437e8e03..3128bede0 100644
--- a/grub-core/commands/tpm.c
+++ b/grub-core/commands/tpm.c
@@ -103,10 +103,21 @@ struct grub_file_verifier grub_tpm_verifier = {
GRUB_MOD_INIT (tpm)
{
+ /*
+ * Even though this now calls ibmvtpm's grub_tpm_present() from
+ * GRUB_MOD_INIT(), it does seem to call it late enough in the initialization
+ * sequence so that whatever discovered 'device nodes' before this
+ * GRUB_MOD_INIT() is called, enables the ibmvtpm driver to see the device
+ * nodes.
+ */
+ if (!grub_tpm_present())
+return;
grub_verifier_register (&grub_tpm_verifier);
}
GRUB_MOD_FINI (tpm)
{
+ if (!grub_tpm_present())
+return;
grub_verifier_unregister (&grub_tpm_verifier);
}
diff --git a/include/grub/tpm.h b/include/grub/tpm.h
index 5c285cbc5..c19fcbd0a 100644
--- a/include/grub/tpm.h
+++ b/include/grub/tpm.h
@@ -36,4 +36,5 @@
grub_err_t grub_tpm_measure (unsigned char *buf, grub_size_t size,
grub_uint8_t pcr, const char *description);
+int grub_tpm_present (void);
#endif
--
2.39.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] tpm: Disable tpm verifier if tpm is not present
On Tue, Nov 29, 2022 at 04:11:48PM +0100, Daniel Kiper wrote: > On Fri, Nov 25, 2022 at 03:00:48PM +0800, Michael Chang via Grub-devel wrote: > > On Thu, Nov 24, 2022 at 05:04:48PM +0100, Daniel Kiper wrote: > > > On Mon, Oct 17, 2022 at 01:19:08PM +0800, Michael Chang via Grub-devel > > > wrote: > > > > On Fri, Oct 14, 2022 at 11:40:01AM +0200, Daniel Kiper wrote: > > > > > On Fri, Oct 07, 2022 at 01:37:10PM +0800, Michael Chang via > > > > > Grub-devel wrote: > > > > > > This helps to prevent out of memory error when reading large files > > > > > > via disabling > > > > > > tpm device as verifier has to read all content into memory in one > > > > > > chunk to > > > > > > measure the hash and extend to tpm. > > > > > > > > > > How does this patch help when the TPM is present in the system? > > > > > > > > If the firmware menu offers option to disable TPM device, then this > > > > patch can be useful to get around 'out of memory error' through > > > > disabling TPM device from firmware in order to make tpm verifier won't > > > > be in the way of reading huge files. > > > > > > > > This is essentially a compromised solution as long as tpm module can be > > > > a built-in module in signed image and at the same time user may come > > > > across the need to open huge files, for eg, loopback mount in grub for > > > > the rescue image. In this case they could be opted in to disable tpm > > > > device from firmware to proceed if they run into out of memory or other > > > > (slow) reading issues. > > > > > > I think I would prefer something similar to this [1] patch. Of course > > > if [1] is not enough... > > > > The tpm verifier attempts to set GRUB_VERIFY_FLAGS_SINGLE_CHUNK for all > > incoming files, which gets loaded into memory in its entirety as an > > duplicated copy to disk files. The overhead is too huge to some low > > profile hardwares with smaller memory or when the boot path has to cover > > very large files, hence the out of memory error. > > > > I think it inevitable to use GRUB_VERIFY_FLAGS_SINGLE_CHUNK as tpm > > measures and extends file intergrity. But we ought to avoid the overhead > > when TPM device is not present or disabled by the user. > > > > The patch [1] seems to deal with the tpm error which prevents a file > > from being opened, which is orthogonal to the memory allocation issue in > > the common verifier before tpm doing measurement. > > This is what I expected. So, that is why I said "Of course if [1] is not > enough..."... :-) Now I think it would be nice if TPM verifier is > disabled when the TPM device is broken/disabled/... and/or somebody sets > a separate environemnt variable in the GRUB. WDYT? I'm not sure if a separate environment a good idea, because it would expose the funtion to disable verifier in a way much readily accessible through one of grub command line interface, grub.cfg and grubenv file so that the intention have to be very carefully reviewed here. Thanks, Michael > > Daniel > > [1] > http://git.savannah.gnu.org/gitweb/?p=grub.git;a=commit;h=a4356538d03c5a5350790b6453b523fb9214c2e9 > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] tpm: Disable tpm verifier if tpm is not present
On Thu, Feb 16, 2023 at 01:02:00PM -0500, Stefan Berger wrote:
>
>
> On 10/7/22 01:37, Michael Chang via Grub-devel wrote:
> > This helps to prevent out of memory error when reading large files via
> > disabling
> > tpm device as verifier has to read all content into memory in one chunk to
> > measure the hash and extend to tpm.
>
> For ibmvtpm driver support this change here would be need. Can you merge it
> into your patch once the ibmvtpm driver is in the repo?
>
> diff --git a/grub-core/commands/ieee1275/ibmvtpm.c
> b/grub-core/commands/ieee1275/ibmvtpm.c
> index 239942d27..e01759c17 100644
> --- a/grub-core/commands/ieee1275/ibmvtpm.c
> +++ b/grub-core/commands/ieee1275/ibmvtpm.c
> @@ -135,16 +135,6 @@ grub_err_t
> grub_tpm_measure (unsigned char *buf, grub_size_t size, grub_uint8_t pcr,
> const char *description)
> {
> - /*
> - * Call tpm_init() 'late' rather than from GRUB_MOD_INIT() so that device
> nodes
> - * can be found.
> - */
> - grub_err_t err = tpm_init ();
> -
> - /* Absence of a TPM isn't a failure. */
> - if (err != GRUB_ERR_NONE)
> -return GRUB_ERR_NONE;
> -
>grub_dprintf ("tpm", "log_event, pcr = %d, size = 0x%" PRIxGRUB_SIZE ",
> %s\n",
> pcr, size, description);
>
> @@ -153,3 +143,13 @@ grub_tpm_measure (unsigned char *buf, grub_size_t size,
> grub_uint8_t pcr,
>
>return GRUB_ERR_NONE;
> }
> +
> +int
> +grub_tpm_present (void)
> +{
> + /*
> + * Call tpm_init() 'late' rather than from GRUB_MOD_INIT() so that device
> nodes
> + * can be found.
> + */
> + return tpm_init() == GRUB_ERR_NONE;
> +}
>
>
> Signed-off-by: Stefan Berger
>
> > diff --git a/grub-core/commands/tpm.c b/grub-core/commands/tpm.c
> > index 2052c36ea..cb8ed6b94 100644
> > --- a/grub-core/commands/tpm.c
> > +++ b/grub-core/commands/tpm.c
> > @@ -86,10 +86,14 @@ struct grub_file_verifier grub_tpm_verifier = {
> > GRUB_MOD_INIT (tpm)
> > {
> > + if (!grub_tpm_present())
> > +return;
>
> Even though this now calls grub_tpm_present() from GRUB_MOD_INIT() and I have
> this comment in the code
> above, it does seem to call it late enough in the initialization sequence so
> that whatever discovered
> 'device nodes' before your GRUB_MOD_INIT() is called, enables the ibmvtpm
> driver to see the device nodes.
Thanks to the clarification. I think it is worth to keep this comment in
the patched hunk so the reader won't get confused by the comment
followed in grub_tpm_present.
>
> Per my tests powerpc grub now measures and logs for PCR 8 and 9 correctly and
> also extends PCRs 8 & 9.
> I hope that nothing will change this initialization order because there seems
> to be little control over it.
I will merge you change and submit a new version.
Thanks.
Michael
>
>Stefan
>
> > grub_verifier_register (&grub_tpm_verifier);
> > }
> > GRUB_MOD_FINI (tpm)
> > {
> > + if (!grub_tpm_present())
> > +return;
> > grub_verifier_unregister (&grub_tpm_verifier);
> > }
> > diff --git a/include/grub/tpm.h b/include/grub/tpm.h
> > index 5c285cbc5..c19fcbd0a 100644
> > --- a/include/grub/tpm.h
> > +++ b/include/grub/tpm.h
> > @@ -36,4 +36,5 @@
> > grub_err_t grub_tpm_measure (unsigned char *buf, grub_size_t size,
> > grub_uint8_t pcr, const char *description);
> > +int grub_tpm_present (void);
> > #endif
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC PATCH 4/4] kern/efi/sb: Use shim to verify font files
On Tue, Dec 06, 2022 at 11:09:57AM -0500, Robbie Harwood wrote: > Zhang Boyang writes: > > > Since font files can be wrapped as PE images by grub-wrap, use shim to > > verify font files if Secure Boot is enabled. To prevent other PE files > > (e.g. kernel images) used as wrappers, it only allows files marked as > > Windows GUI used as wrappers. > > Thanks for writing this; it's helpful to have something concrete to look > at. > > This approach is very font-focused, and while I understand that given > the discussion, I do still wonder if it wouldn't be better to make fonts > an instance of modules. If fonts become instances of modules, and > modules are wrapped into PE files, that not only seems cleaner but also > gives us signed module support without baking those into the image. Why not just making the PE wrap applicable to all file types, be it font files, grub modules or even (static) initrd. Providing a solution to sign arbitrary data or binary with this PE envelope sounds to me a very attractive feature and worthwhile the extra miles. :) Thanks, Michael > > What do you think? > > Be well, > --Robbie ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Fonts and theming and what to do in future with SB
On Tue, Nov 29, 2022 at 03:24:51PM -0500, Robbie Harwood wrote: > Steve McIntyre writes: > > > Hey folks! > > > > So, with the latest set of GRUB CVE patches we've fixed up a bunch of > > potential crashes in font-handling code that could lead to Secure Boot > > holes. These are good and useful fixes, and thanks to Zhang Boyang and > > everyone else involved! > > > > There were also a few other changes: > > > > * In SB mode, refuse to load fonts from outside of the signed GRUB > >image > > * Restrictions to image dimensions > > * Fix integer overflow in fbutil > > > > Locking down fonts here has caused some issues that I've seen. > > > > We didn't update the config generation code in util/grub.d, so we're > > still generating grub.cfg files that will try (and fail!) to load > > fonts from other locations at runtime in SB mode. This causes ugly > > errors, and also causes GRUB to fail to set up video as normal. We can > > fix this, but it would be nice to agree on something upstream rather > > than as diverging distro patches. > > > > AFAIK Chris Coulson has a patch for the font loader to cause it to try > > loading fonts from the embedded memdisk first. Is that the best > > approach? If so, what fonts should we be embedding in the signed > > image? It's a tradeoff between size and functionality, of course - > > some people are happy with just "unicode" while others may want a > > wider choice for added theming options. Is the size an issue for most > > people? > > > > Or... Could/should we look at options to sign fonts separately? I've > > heard suggestions to embed them into faked-up modules that we could > > load with insmod, but of course we don't support signing modules yet > > anyway... :-) > > I personally don't like that we *pretend* we do have signed modules - > that is, we pretend that `insmod` works when it doesn't. (I am > ambivalent on whether we should have signed standalone module support in > general.) So while I appreciate Chris's patch and am shipping it, I > don't think faking `loadfont` too is a good longer-term solution. > > I understood that these kinds of decisions have been made because it's > easier than patching the config generation code. I know we're getting > into "boil the ocean" territory, but maybe there's work that could be > done to improve that situation? In general the feedback I've been > getting on grub config is that it would be nice if we had less of it, > for whatever that's worth. > > It's also odd that we've elected to lock down fonts in this way but not > images. Perhaps this is a good opportunity to rethink how much > customization we actually want to provide to distros and end users of > our packages. Concretely, it seems that we expose customization for > three use cases: > > 1. Distro branding. A Debian or RHEL or what have you wants to make >their ISO perhaps say the distro name at the top and have a logo >background or something. > > 2. Localization. It is reasonable for users to want prompts and text on >the screen to appear in the language of their choice. > > 3. Making it look cool / use the font I want / etc. > > I think localization is resolved by bundling the unicode font, and it's > a good idea to default to having that around. Distro branding seems to > me a limited use case - we can just bundle whatever we need for that > into our signed images, if we want. I'm less interested in any other > customization: in RHEL and Fedora, we generally don't show a menu at > all. I would not personally be upset if we just removed most of the > customizability - but I'm also not the target audience. In SUSE/openSUSE we still keep up the tradition of using graphical themed bootloader menu to *green* users as default, from grub/isolinux gfxboot in the early days to the grub2 theme engine today. There are also many of the users spending lots of their time as a hobby to make a good looking theme and try to spreading their artwork. Removing the customizability out of the source code and kill this feature will certainly disappoint users who has been using grub for this long, including me. > > Thanks Steve for raising the issue on-list. I'm curious what other > distro vendors here think too. I'm also advocated for a solution which is transparent to the generated config so will pick up the patch from Chris. In that way probably we could come up with a default directory in memdisk, say (memdisk)/font, that grub will scan and load the fonts upfront during start up to provide basic font support for default theme besides to external fonts. Thanks, Michael > > Be well, > --Robbie > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] tpm: Disable tpm verifier if tpm is not present
On Thu, Nov 24, 2022 at 05:04:48PM +0100, Daniel Kiper wrote: > On Mon, Oct 17, 2022 at 01:19:08PM +0800, Michael Chang via Grub-devel wrote: > > On Fri, Oct 14, 2022 at 11:40:01AM +0200, Daniel Kiper wrote: > > > On Fri, Oct 07, 2022 at 01:37:10PM +0800, Michael Chang via Grub-devel > > > wrote: > > > > This helps to prevent out of memory error when reading large files via > > > > disabling > > > > tpm device as verifier has to read all content into memory in one chunk > > > > to > > > > measure the hash and extend to tpm. > > > > > > How does this patch help when the TPM is present in the system? > > > > If the firmware menu offers option to disable TPM device, then this > > patch can be useful to get around 'out of memory error' through > > disabling TPM device from firmware in order to make tpm verifier won't > > be in the way of reading huge files. > > > > This is essentially a compromised solution as long as tpm module can be > > a built-in module in signed image and at the same time user may come > > across the need to open huge files, for eg, loopback mount in grub for > > the rescue image. In this case they could be opted in to disable tpm > > device from firmware to proceed if they run into out of memory or other > > (slow) reading issues. > > I think I would prefer something similar to this [1] patch. Of course > if [1] is not enough... The tpm verifier attempts to set GRUB_VERIFY_FLAGS_SINGLE_CHUNK for all incoming files, which gets loaded into memory in its entirety as an duplicated copy to disk files. The overhead is too huge to some low profile hardwares with smaller memory or when the boot path has to cover very large files, hence the out of memory error. I think it inevitable to use GRUB_VERIFY_FLAGS_SINGLE_CHUNK as tpm measures and extends file intergrity. But we ought to avoid the overhead when TPM device is not present or disabled by the user. The patch [1] seems to deal with the tpm error which prevents a file from being opened, which is orthogonal to the memory allocation issue in the common verifier before tpm doing measurement. Thanks, Michael > > Daniel > > [1] > http://git.savannah.gnu.org/gitweb/?p=grub.git;a=commit;h=a4356538d03c5a5350790b6453b523fb9214c2e9 > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.12 release - update
Dear Daniel, On Wed, Oct 26, 2022 at 04:52:09PM +0200, Daniel Kiper wrote: > Hi, > > We are getting closer to the 2.12 release. Sadly we still do not have > many of important patch sets in the tree. So, I am going to spend more > time on reviews in the following weeks. Below you can find my list of > key patch sets which should land in the release: > - Dynamic allocation of memory regions and IBM vTPM v2, > - Unify ARM64 & RISC-V Linux Loader, > - Add support for LoongArch, > - plainmount: Support plain encryption mode, > - Glenn's tests fixes. > > Of course all patches which got my RB or are under review will be merged too. > > There is also "nice to have" list but I do not consider lack of this > patch sets as release blockers: > - Add support for EFI file system transposition, > - term/serial: Add support for PCI serial devices, > - Add MMIO serial ports support and SPCR detection, > - Glenn's gdb patch set. > > I hope I will be able to review and merge all patch sets from first list > during November. Then if everything goes well we will make code freeze > in December and release at the beginning of next year, preferably in January. > > I am considering to not block merges for tests and documentation during > code freeze. > > If you have any comments on that plan please drop me a line. Is there any chance to get argon2 support [1] in 2.12 ? Given the required memory manager patch has been merged to allow allocating huge chunks of data in heap, it seems all is ready to go now ? This is the major feature brought by LUKS2 making it really a successor to LUKS1 IMHO. [1] https://lists.gnu.org/archive/html/grub-devel/2021-08/msg00027.html Thanks, Michael > > Daniel > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v4] templates: introduce GRUB_TOP_LEVEL_* vars
On Tue, Oct 18, 2022 at 04:18:21PM +0200, Olaf Hering wrote: > Tue, 18 Oct 2022 06:57:36 -0700 Denton Liu : > > > If I'm understanding correctly, what you're proposing is a mechanism for > > setting the default entry. If I'm not mistaken, this seems like an > > orthogonal discussion to me. My patch proposes a method of setting the > > top-level menu entry while this method only sets the default entry, > > which may be hidden behind a submenu. > > I think this can be done already today. At least YaST offers a way to select > a specific item in a submenu and pass it to grub-set-default. This leads to > an entry like this in grubenv: > > saved_entry=Advanced options for SLE15SP4 (with Xen hypervisor)>Xen > hypervisor, version > 4.17.20220823T122205.399bcbf2-xen_unstable.150400.370>SLE15SP4, with Xen > 4.17.20220823T122205.399bcbf2-xen_unstable.150400.370 and Linux > 5.14.21-150400.24.21-default > > This entry will be booted as long as both this specific Xen version and this > specific kernel version is found. There is a slim chance a SUSE specific > patch exists to enable this functionality. Just to clarify. There is no specific patch, this is common function in grub. Thanks, Michael > > Maybe the patch description lacks a specific example how the proposed change > is supposed to be used in your environment. > > Olaf > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] tpm: Disable tpm verifier if tpm is not present
On Fri, Oct 14, 2022 at 11:40:01AM +0200, Daniel Kiper wrote: > On Fri, Oct 07, 2022 at 01:37:10PM +0800, Michael Chang via Grub-devel wrote: > > This helps to prevent out of memory error when reading large files via > > disabling > > tpm device as verifier has to read all content into memory in one chunk to > > measure the hash and extend to tpm. > > How does this patch help when the TPM is present in the system? If the firmware menu offers option to disable TPM device, then this patch can be useful to get around 'out of memory error' through disabling TPM device from firmware in order to make tpm verifier won't be in the way of reading huge files. This is essentially a compromised solution as long as tpm module can be a built-in module in signed image and at the same time user may come across the need to open huge files, for eg, loopback mount in grub for the rescue image. In this case they could be opted in to disable tpm device from firmware to proceed if they run into out of memory or other (slow) reading issues. Thanks, Michael > > Daniel > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] tpm: Disable tpm verifier if tpm is not present
On Thu, Oct 06, 2022 at 03:40:36PM -0400, Stefan Berger wrote:
>
>
> On 9/8/22 00:23, Michael Chang via Grub-devel wrote:
> > This helps to prevent out of memory error when reading large files via
> > disablig
> > tpm device as verifier has to read all content into memory in one chunk to
> > measure the hash and extend to tpm.
> >
> > Signed-off-by: Michael Chang
> > ---
> > grub-core/commands/efi/tpm.c | 37
> > grub-core/commands/tpm.c | 4
> > include/grub/tpm.h | 1 +
> > 3 files changed, 42 insertions(+)
> >
> > diff --git a/grub-core/commands/efi/tpm.c b/grub-core/commands/efi/tpm.c
> > index ae09c1bf8b..4f0011f6f5 100644
> > --- a/grub-core/commands/efi/tpm.c
> > +++ b/grub-core/commands/efi/tpm.c
> > @@ -287,3 +287,40 @@ grub_tpm_measure (unsigned char *buf, grub_size_t
> > size, grub_uint8_t pcr,
> > else
> > return grub_tpm2_log_event (tpm_handle, buf, size, pcr, description);
> > }
> > +
> > +int
> > +grub_tpm_present ()
>
> nit: void
I'll fix in next version.
>
> > +{
> > + grub_efi_handle_t tpm_handle;
> > + grub_efi_uint8_t protocol_version;
> > +
> > + if (!grub_tpm_handle_find (&tpm_handle, &protocol_version))
> > +return 0;
> > +
> > + if (protocol_version == 1)
> > +{
> > + grub_efi_tpm_protocol_t *tpm;
> > +
> > + tpm = grub_efi_open_protocol (tpm_handle, &tpm_guid,
> > + GRUB_EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> > + if (!tpm)
> > + {
> > + grub_dprintf ("tpm", "Cannot open TPM protocol\n");
> > + return 0;
> > + }
> > + return grub_tpm1_present (tpm);
> > +}
> > + else
> > +{
> > + grub_efi_tpm2_protocol_t *tpm;
> > +
> > + tpm = grub_efi_open_protocol (tpm_handle, &tpm2_guid,
> > + GRUB_EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> > + if (!tpm)
> > + {
> > + grub_dprintf ("tpm", "Cannot open TPM protocol\n");
> > + return 0;
> > + }
> > + return grub_tpm2_present (tpm);
> > +}
> > +}
> > diff --git a/grub-core/commands/tpm.c b/grub-core/commands/tpm.c
> > index 2052c36eab..cb8ed6b949 100644
> > --- a/grub-core/commands/tpm.c
> > +++ b/grub-core/commands/tpm.c
> > @@ -86,10 +86,14 @@ struct grub_file_verifier grub_tpm_verifier = {
> > GRUB_MOD_INIT (tpm)
> > {
> > + if (!grub_tpm_present())
> > +return;
> > grub_verifier_register (&grub_tpm_verifier);
> > }
> > GRUB_MOD_FINI (tpm)
> > {
> > + if (!grub_tpm_present())
> > +return;
> > grub_verifier_unregister (&grub_tpm_verifier);
> > }
> > diff --git a/include/grub/tpm.h b/include/grub/tpm.h
> > index 5c285cbc52..c19fcbd0a6 100644
> > --- a/include/grub/tpm.h
> > +++ b/include/grub/tpm.h
> > @@ -36,4 +36,5 @@
> > grub_err_t grub_tpm_measure (unsigned char *buf, grub_size_t size,
> > grub_uint8_t pcr, const char *description);
> > +int grub_tpm_present (void);
> > #endif
>
> Reviewed-by: Stefan Berger
I will add your Reviewed-by in next version too.
Thanks,
Michael
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2] tpm: Disable tpm verifier if tpm is not present
This helps to prevent out of memory error when reading large files via disabling
tpm device as verifier has to read all content into memory in one chunk to
measure the hash and extend to tpm.
Signed-off-by: Michael Chang
Reviewed-by: Stefan Berger
---
grub-core/commands/efi/tpm.c | 37
grub-core/commands/tpm.c | 4
include/grub/tpm.h | 1 +
3 files changed, 42 insertions(+)
diff --git a/grub-core/commands/efi/tpm.c b/grub-core/commands/efi/tpm.c
index ae09c1bf8..e1f343fea 100644
--- a/grub-core/commands/efi/tpm.c
+++ b/grub-core/commands/efi/tpm.c
@@ -287,3 +287,40 @@ grub_tpm_measure (unsigned char *buf, grub_size_t size,
grub_uint8_t pcr,
else
return grub_tpm2_log_event (tpm_handle, buf, size, pcr, description);
}
+
+int
+grub_tpm_present (void)
+{
+ grub_efi_handle_t tpm_handle;
+ grub_efi_uint8_t protocol_version;
+
+ if (!grub_tpm_handle_find (&tpm_handle, &protocol_version))
+return 0;
+
+ if (protocol_version == 1)
+{
+ grub_efi_tpm_protocol_t *tpm;
+
+ tpm = grub_efi_open_protocol (tpm_handle, &tpm_guid,
+ GRUB_EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+ if (!tpm)
+ {
+ grub_dprintf ("tpm", "Cannot open TPM protocol\n");
+ return 0;
+ }
+ return grub_tpm1_present (tpm);
+}
+ else
+{
+ grub_efi_tpm2_protocol_t *tpm;
+
+ tpm = grub_efi_open_protocol (tpm_handle, &tpm2_guid,
+ GRUB_EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+ if (!tpm)
+ {
+ grub_dprintf ("tpm", "Cannot open TPM protocol\n");
+ return 0;
+ }
+ return grub_tpm2_present (tpm);
+}
+}
diff --git a/grub-core/commands/tpm.c b/grub-core/commands/tpm.c
index 2052c36ea..cb8ed6b94 100644
--- a/grub-core/commands/tpm.c
+++ b/grub-core/commands/tpm.c
@@ -86,10 +86,14 @@ struct grub_file_verifier grub_tpm_verifier = {
GRUB_MOD_INIT (tpm)
{
+ if (!grub_tpm_present())
+return;
grub_verifier_register (&grub_tpm_verifier);
}
GRUB_MOD_FINI (tpm)
{
+ if (!grub_tpm_present())
+return;
grub_verifier_unregister (&grub_tpm_verifier);
}
diff --git a/include/grub/tpm.h b/include/grub/tpm.h
index 5c285cbc5..c19fcbd0a 100644
--- a/include/grub/tpm.h
+++ b/include/grub/tpm.h
@@ -36,4 +36,5 @@
grub_err_t grub_tpm_measure (unsigned char *buf, grub_size_t size,
grub_uint8_t pcr, const char *description);
+int grub_tpm_present (void);
#endif
--
2.35.3
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] tpm: Disable tpm verifier if tpm is not present
This helps to prevent out of memory error when reading large files via disablig
tpm device as verifier has to read all content into memory in one chunk to
measure the hash and extend to tpm.
Signed-off-by: Michael Chang
---
grub-core/commands/efi/tpm.c | 37
grub-core/commands/tpm.c | 4
include/grub/tpm.h | 1 +
3 files changed, 42 insertions(+)
diff --git a/grub-core/commands/efi/tpm.c b/grub-core/commands/efi/tpm.c
index ae09c1bf8b..4f0011f6f5 100644
--- a/grub-core/commands/efi/tpm.c
+++ b/grub-core/commands/efi/tpm.c
@@ -287,3 +287,40 @@ grub_tpm_measure (unsigned char *buf, grub_size_t size,
grub_uint8_t pcr,
else
return grub_tpm2_log_event (tpm_handle, buf, size, pcr, description);
}
+
+int
+grub_tpm_present ()
+{
+ grub_efi_handle_t tpm_handle;
+ grub_efi_uint8_t protocol_version;
+
+ if (!grub_tpm_handle_find (&tpm_handle, &protocol_version))
+return 0;
+
+ if (protocol_version == 1)
+{
+ grub_efi_tpm_protocol_t *tpm;
+
+ tpm = grub_efi_open_protocol (tpm_handle, &tpm_guid,
+ GRUB_EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+ if (!tpm)
+ {
+ grub_dprintf ("tpm", "Cannot open TPM protocol\n");
+ return 0;
+ }
+ return grub_tpm1_present (tpm);
+}
+ else
+{
+ grub_efi_tpm2_protocol_t *tpm;
+
+ tpm = grub_efi_open_protocol (tpm_handle, &tpm2_guid,
+ GRUB_EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+ if (!tpm)
+ {
+ grub_dprintf ("tpm", "Cannot open TPM protocol\n");
+ return 0;
+ }
+ return grub_tpm2_present (tpm);
+}
+}
diff --git a/grub-core/commands/tpm.c b/grub-core/commands/tpm.c
index 2052c36eab..cb8ed6b949 100644
--- a/grub-core/commands/tpm.c
+++ b/grub-core/commands/tpm.c
@@ -86,10 +86,14 @@ struct grub_file_verifier grub_tpm_verifier = {
GRUB_MOD_INIT (tpm)
{
+ if (!grub_tpm_present())
+return;
grub_verifier_register (&grub_tpm_verifier);
}
GRUB_MOD_FINI (tpm)
{
+ if (!grub_tpm_present())
+return;
grub_verifier_unregister (&grub_tpm_verifier);
}
diff --git a/include/grub/tpm.h b/include/grub/tpm.h
index 5c285cbc52..c19fcbd0a6 100644
--- a/include/grub/tpm.h
+++ b/include/grub/tpm.h
@@ -36,4 +36,5 @@
grub_err_t grub_tpm_measure (unsigned char *buf, grub_size_t size,
grub_uint8_t pcr, const char *description);
+int grub_tpm_present (void);
#endif
--
2.35.3
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 2/2] grub-install: Ensure a functional /dev/nvram
On Mon, Aug 29, 2022 at 04:36:25PM +0200, Ismael Luceno wrote:
> This enables an early failure; for i386-ieee1275 and powerpc-ieee1275 on
> Linux, without /dev/nvram the system may be left in an unbootable state.
>
> Signed-off-by: Ismael Luceno
> ---
> util/grub-install.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/util/grub-install.c b/util/grub-install.c
> index 527b85e27aa7..c84a2fb0526f 100644
> --- a/util/grub-install.c
> +++ b/util/grub-install.c
> @@ -827,6 +827,16 @@ fill_core_services (const char *core_services)
>free (sysv_plist);
> }
>
> +static void
> +try_open (const char *path)
> +{
> + FILE *f;
> + f = grub_util_fopen (path, "r+");
> + if (!f)
> +grub_util_error (_("Unable to open %s: %s"), path, strerror(errno));
> + fclose (f);
> +}
> +
> int
> main (int argc, char *argv[])
> {
> @@ -1026,6 +1036,19 @@ main (int argc, char *argv[])
>break;
> }
>
> + switch (platform)
> +{
> +case GRUB_INSTALL_PLATFORM_I386_IEEE1275:
> +case GRUB_INSTALL_PLATFORM_POWERPC_IEEE1275:
> +#ifdef __linux__
> + /* On Linux, ensure /dev/nvram is _functional_. */
> + try_open ("/dev/nvram");
The update_nvram variable should be tested in case user has skipped it.
Thanks,
Michael
> +#endif
> + break;
> +default:
> + break;
> +}
> +
>/* Find the EFI System Partition. */
>
>if (is_efi)
> --
> 2.37.1
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/2] grub-install: Add missing points of no return for IEEE1275 on i386/powerpc
On Mon, Aug 29, 2022 at 04:36:24PM +0200, Ismael Luceno wrote:
> Signed-off-by: Ismael Luceno
> ---
> util/grub-install.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/util/grub-install.c b/util/grub-install.c
> index 7b04bd3c534b..527b85e27aa7 100644
> --- a/util/grub-install.c
> +++ b/util/grub-install.c
> @@ -1835,6 +1835,7 @@ main (int argc, char *argv[])
> {
> if (write_to_disk (ins_dev, imgfile))
> grub_util_error ("%s", _("failed to copy Grub to the PReP
> partition"));
> + grub_set_install_backup_ponr ();
This looks good to me.
> }
> else
> {
> @@ -1859,6 +1860,7 @@ main (int argc, char *argv[])
> partno = grub_dev->disk->partition
> ? grub_dev->disk->partition->number + 1 : 0;
> dev = grub_util_get_os_disk (grub_devices[0]);
> + grub_set_install_backup_ponr ();
This should be moved way up, given failure may occur at
grub_make_system_path_relative_to_its_root or even earlier.
But in the first place the attempt may have been wrong, given the image
is installed as file in the platform directory, there we should not be
botherd to set grub_set_install_backup_ponr as file should be able to be
backup and restored thus is covered. On the other hand, the
grub_set_install_backup_ponr looked like a workaround to me to deal with
raw images embedded in partition that has no good way to restore it.
That is for i386-ieee1275, /boot/grub2/i386-ieee1275/grub should be
added to the list of backup and restore to get it to work in failure
recovery path.
Thanks,
Michael
> grub_install_register_ieee1275 (0, dev,
> partno, relpath);
> }
> --
> 2.37.1
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] grub-install: set point of no return for powerpc-ieee1275 install
The point of no return is used to define a point where no change should
be reverted in a wake of fatal error that consequently aborts the
process. The powerpc-ieee1275 install apparently missed this point of no
return defintion that newly installed modules could be inadvertently
reverted after successful image embedding so that boot failure is
incurred due to inconsistent state.
Signed-off-by: Michael Chang
---
util/grub-install.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/util/grub-install.c b/util/grub-install.c
index 7b04bd3c53..1c0ece7f19 100644
--- a/util/grub-install.c
+++ b/util/grub-install.c
@@ -1835,6 +1835,7 @@ main (int argc, char *argv[])
{
if (write_to_disk (ins_dev, imgfile))
grub_util_error ("%s", _("failed to copy Grub to the PReP
partition"));
+ grub_set_install_backup_ponr ();
}
else
{
--
2.35.3
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/2] Ensure nvram is available and functional on IEEE1275
On Wed, Aug 24, 2022 at 06:03:11PM +0200, Ismael Luceno wrote:
> Otherwise the installation will fail, and the system will be left in an
> unbootable state.
>
> On ppc64le, the boot process shows:
>
> Welcome to GRUB!
>
> error: ../../grub-core/kern/dl.c:380:symbol `grub_disk_get_size' not
> found.
> Entering rescue mode...
> grub rescue>
The symbol looking up failure due to failed grub-install attempt should
not happen in the first place given this commit should bail it out.
8ddbdc3bc2 grub-install: Add backup and restore
Apparently there's missing grub_set_install_backup_ponr between
successful image embedding and grub_install_register_ieee1275 and we
should fix that as well.
>
> Signed-off-by: Ismael Luceno
> ---
> grub-core/osdep/unix/platform.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/grub-core/osdep/unix/platform.c b/grub-core/osdep/unix/platform.c
> index a5bf064b7cf5..fd23176e58a0 100644
> --- a/grub-core/osdep/unix/platform.c
> +++ b/grub-core/osdep/unix/platform.c
> @@ -192,12 +192,30 @@ grub_install_register_efi (grub_device_t
> efidir_grub_dev,
>return ret;
> }
>
> +static void
> +linux_ensure_nvram (void)
> +{
> + int fd;
> +#ifndef __linux__
> + return 0;
> +#endif
> + if (linux_kmod_load("nvram"))
> +grub_util_error (_("%s: kernel module not found"), "nvram");
> + fd = open ("/dev/nvram", O_RDWR);
> + if (fd == -1)
> +grub_util_error ("/dev/nvram: %s", strerror(errno));
> + close (fd);
> +}
> +
I'm wondering why it is needed. The nvram module should be loaded
on-demand via linux kernel's request_module() and modalias trick whever
/dev/nvram is accessed.
Thanks,
Michael
> void
> grub_install_register_ieee1275 (int is_prep, const char *install_device,
> int partno, const char *relpath)
> {
>char *boot_device;
>
> + /* On Linux, ensure nvram is available and functional. */
> + linux_ensure_nvram ();
> +
>if (grub_util_exec_redirect_null ((const char * []){ "ofpathname",
> "--version", NULL }))
> {
>/* TRANSLATORS: This message is shown when required executable `%s'
> --
> 2.37.1
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v4 2/2] devmapper/getroot: Set up cheated LUKS2 cryptodisk mount from DM parameters
On Tue, Jun 14, 2022 at 03:47:30PM +0200, The development of GNU GRUB wrote:
> This lets a LUKS2 cryptodisk have its cipher and hash filled out,
> otherwise they wouldn't be initialized if cheat mounted.
> ---
> grub-core/osdep/devmapper/getroot.c | 91 -
> 1 file changed, 90 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/osdep/devmapper/getroot.c
> b/grub-core/osdep/devmapper/getroot.c
> index 2bf4264cf..ac90761ea 100644
> --- a/grub-core/osdep/devmapper/getroot.c
> +++ b/grub-core/osdep/devmapper/getroot.c
> @@ -51,6 +51,8 @@
> #include
> #include
>
> +#include
> +
> static int
> grub_util_open_dm (const char *os_dev, struct dm_tree **tree,
> struct dm_tree_node **node)
> @@ -186,7 +188,6 @@ grub_util_pull_devmapper (const char *os_dev)
>&& lastsubdev)
> {
>char *grdev = grub_util_get_grub_dev (lastsubdev);
> - dm_tree_free (tree);
>if (grdev)
> {
> grub_err_t err;
> @@ -194,7 +195,95 @@ grub_util_pull_devmapper (const char *os_dev)
> if (err)
> grub_util_error (_("can't mount encrypted volume `%s': %s"),
>lastsubdev, grub_errmsg);
> + if (strncmp (uuid, "CRYPT-LUKS2-", sizeof ("CRYPT-LUKS2-") - 1) ==
> 0)
> +{
> + /* set LUKS2 cipher from dm parameters, since it is not
> + * possible to determine the correct one without
> + * unlocking, as there might be multiple segments.
> + */
> + grub_disk_t source;
> + grub_cryptodisk_t cryptodisk;
> + grub_addr_t start, length;
Just a heads up. This failed to build on 32-bit architectures (i586,
armv7l) with following error:
[ 141s] ../grub-core/osdep/devmapper/getroot.c: In function
'grub_util_pull_devmapper':
[ 141s] ../grub-core/osdep/devmapper/getroot.c:234:46: error: passing argument
3 of 'dm_get_next_target' from incompatible pointer type
[-Werror=incompatible-pointer-types]
[ 141s] 234 | dm_get_next_target (dmt, NULL, &start, &length,
[ 141s] | ^~
[ 141s] | |
[ 141s] | grub_addr_t *
{aka unsigned int *}
[ 141s] In file included from ../grub-core/osdep/devmapper/getroot.c:44:
[ 141s] /usr/include/libdevmapper.h:288:48: note: expected 'uint64_t *' {aka
'long long unsigned int *'} but argument is of type 'grub_addr_t *' {aka
'unsigned int *'}
[ 141s] 288 | void *next, uint64_t *start, uint64_t
*length,
[ 141s] | ~~^
[ 141s] ../grub-core/osdep/devmapper/getroot.c:234:54: error: passing argument
4 of 'dm_get_next_target' from incompatible pointer type
[-Werror=incompatible-pointer-types]
[ 141s] 234 | dm_get_next_target (dmt, NULL, &start, &length,
[ 141s] | ^~~
[ 141s] | |
[ 141s] |
grub_addr_t * {aka unsigned int *}
[ 141s] /usr/include/libdevmapper.h:288:65: note: expected 'uint64_t *' {aka
'long long unsigned int *'} but argument is of type 'grub_addr_t *' {aka
'unsigned int *'}
[ 141s] 288 | void *next, uint64_t *start, uint64_t
*length,
[ 141s] |
~~^~
Apparently changing to use 'grub_uint64_t' for both start and length
fixed the problem for me.
Thanks,
Michael
> + char *target_type;
> + char *params;
> + const char *name;
> + char *cipher, *cipher_mode;
> + struct dm_task *dmt;
> + char *seek_head, *c;
> + unsigned int remaining;
> +
> + source = grub_disk_open (grdev);
> + cryptodisk = grub_cryptodisk_get_by_source_disk (source);
> + grub_disk_close (source);
> +
> + name = dm_tree_node_get_name (node);
> +
> + grub_util_info ("populating parameters of cryptomount `%s'
> from DM device `%s'",
> + uuid, name);
> +
> + dmt = dm_task_create (DM_DEVICE_TABLE);
> + if (dmt == 0)
> +grub_util_error (_("can't create dm task DM_DEVICE_TABLE"));
> + if (dm_task_set_name (dmt, name) == 0)
> +grub_util_error (_("can't set dm task name to `%s'"), name);
> + if (dm_task_run (dmt) == 0)
> +grub_util_error (_("can't run dm task for `%s'"), name);
> + /* dm_get_next_target doesn't have any error modes, everything
> has
> + * been handled by dm_task_run.
> + */
> + dm_get_next_target (dmt,
Re: Support for unsealing TPM keys in GRUB
On Fri, Jun 03, 2022 at 03:56:10PM +0530, sinfinity 85 wrote: > Hi > We need to unseal TPM keys in GRUB2 (2.0.4) in order to decrypt the kernel > and load it. But, I see that there's no support for unsealing keys in GRUB2. > However, support for unsealing keys is present in TrustedGrub.Has anyone > tried to incorporate this into the GRUB2 source? Would there be any > challenges to this? FYI. There's outstanding work of integrating TPM 2.0 unsealing to the UEFI platform. https://lists.gnu.org/archive/html/grub-devel/2022-02/msg6.html Thanks, Michael > > Thanks, > Ram. > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC PATCH v3 5/5] Cleanup: grub-mkconfig_lib: remove unused version comparison functions
On Thu, May 26, 2022 at 05:07:11PM -0400, Robbie Harwood wrote: > Mathieu Desnoyers writes: > > > There are no users left of version_find_latest(), version_test_gt(), and > > version_test_numeric(). Remove those unused helper functions. Using > > those helper functions is what caused the quadratic sorting performance > > issues in the first place, so removing them is a net win. > > > > Signed-off-by: Mathieu Desnoyers > > Reviewed-by: Robbie Harwood Hm. This seems to contradict your proposed patch to use distro specific sort by hooking into those functions got removed here. mkconfig: use distro sorts when available https://www.mail-archive.com/grub-devel@gnu.org/msg33357.html I'd like to know more your comments about this as those hooks might still be needed or where to keep distribution's sort ? Thanks, Michael > > Be well, > --Robbie > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 15/19] appended signatures: parse PKCS#7 signedData and X.509 certificates
On Thu, Apr 21, 2022 at 09:32:41PM +1000, Daniel Axtens wrote:
> Hi,
>
> >> This code allows us to parse:
> >>
> >> - PKCS#7 signedData messages. Only a single signerInfo is supported,
> >>which is all that the Linux sign-file utility supports creating
> >>out-of-the-box. Only RSA, SHA-256 and SHA-512 are supported.
> >>Any certificate embedded in the PKCS#7 message will be ignored.
> >>
> >> - X.509 certificates: at least enough to verify the signatures on the
> >>PKCS#7 messages. We expect that the certificates embedded in grub will
> >>be leaf certificates, not CA certificates. The parser enforces this.
> >
> > Doesn't grub support CA certificates for EFI?
> >
> For EFI, the verification isn't done by grub, it's done by either the
> shim or by firmware. They do - per the spec - support certificate
> chaining. So you could validly put a CA cert into db or MokList and have
> a signature on an Authenticode signature chain back to that.
>
> > Why limit to leaf certificates here?
>
> Conventionally, appended signatures don't include embedded certificates
> whereas Authenticode signatures do. There's nothing stopping you putting
> one into the PKCS#7 message for an appended signature - it's just not
> the way they are used on kernel modules or kernel binaries. So if
> there's not an embedded certificate that can chain back to a CA
> certificate, grub has to have access to the leaf certificate.
>
> > If this is technical limitation of the code in question could you fail
> > the build when CA certificate is used rather than crashing the
> > bootloader when it boots?
>
> I guess. I think IBM has been reasonably open in saying that static key
> secure boot is not the end of the road for Power, so we expect that
> ultimately keys could be loaded from somewhere other than the binary
> like firmware storage. So even if we added this check in grub-mkimage,
> we'd still need to keep it at runtime as well.
>
> >> - X.509 certificates support the Extended Key Usage extension and handle
> >>it by verifying that the certificate has a single purpose, that is code
> > ^^
> > This should be updated I suppose.
>
> So this is - surprisingly - still accurate! We still only support 1
> _Extended_ Key Usage. The change that we made as a result of SUSE's bug
It is unclear to me OpenFirmware enforces such restriction as well ? My
understanding is that the (single purpose) restriction is lifed in
firmware becuase it happily accepts our cert and boots SUSE signed grub
in secure boot without complaining Key Usage. If so I wonder why it is
necessary for having the stricter check in grub ?
> report was to support additional regular, non-extended key
> usages. Here's the change broken out:
Would this change be used next version ?
Thanks,
Michael
>
> commit 6056d5fc59907c486309c401135757f00ebf7760
> Author: Daniel Axtens
> Date: Tue Nov 30 15:00:57 2021 +1100
>
> x509: allow Digitial Signature plus other Key Usages
>
> Currently the x509 certificate parser for appended signature
> verification requires that the certificate have the Digitial Signature
> key usage and _only_ the Digitial Signature use. This is overly strict
> and becomes policy enforcement rather than a security property.
>
> Require that the Digitial Signature usage is present, but do not
> require that it is the only usage present.
>
> Reported-by: Michal Suchanek
> Signed-off-by: Daniel Axtens
>
> diff --git a/grub-core/commands/appendedsig/x509.c
> b/grub-core/commands/appendedsig/x509.c
> index 70480aa73c9d..6ae985b30ff8 100644
> --- a/grub-core/commands/appendedsig/x509.c
> +++ b/grub-core/commands/appendedsig/x509.c
> @@ -547,7 +547,7 @@ cleanup:
>
> /*
> * Verify the Key Usage extension.
> - * We only permit the Digital signature usage.
> + * We require the Digital signature usage.
> */
> static grub_err_t
> verify_key_usage (grub_uint8_t *value, int value_size)
> @@ -586,10 +586,10 @@ verify_key_usage (grub_uint8_t *value, int value_size)
>goto cleanup;
> }
>
> - if (usage != digitalSignatureUsage)
> + if (!(usage & digitalSignatureUsage))
> {
>err =
> - grub_error (GRUB_ERR_BAD_FILE_TYPE, "Unexpected Key Usage value: %x",
> + grub_error (GRUB_ERR_BAD_FILE_TYPE, "Key Usage (0x%x) missing Digital
> Signature usage",
> usage);
>goto cleanup;
> }
>
> Kind regards,
> Daniel
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 2/3] Fix -Werror=array-bounds array subscript 0 is outside array bounds
The grub is failing to build with gcc-12 in many places like this:
In function 'init_cbfsdisk',
inlined from 'grub_mod_init' at ../../grub-core/fs/cbfs.c:391:3:
../../grub-core/fs/cbfs.c:345:7: error: array subscript 0 is outside array
bounds of 'grub_uint32_t[0]' {aka 'unsigned int[]'} [-Werror=array-bounds]
345 | ptr = *(grub_uint32_t *) 0xfffc;
| ^~~
This is caused by gcc regression in 11/12 [1]. In a nut shell, the
warning is about detected invalid accesses at non-zero offsets to NULL
pointers. Since hardwired constant address is treated as NULL plus an
offset in the same underlying code, the warning is therefore triggered.
Instead of inserting #pragma all over the places where literal pointers
are accessed to avoid diagnosing array-bounds, we can try to borrow the
idea from linux kernel that the absolute_pointer macro [2][3] is used to
disconnect a pointer using literal address from it's original object,
hence gcc won't be able to make assumptions on the boundary while doing
pointer arithmetic. With that we can greatly reduce the code we have to
cover up by making initial literal pointer assignment to use the new
wrapper but not having to track everywhere literal pointers are
accessed. This also makes code looks cleaner.
Please note the absolute_pointer macro requires to be invoked in a
function as long as it is compound expression. Some global variables
with literal pointers has been changed to local ones in order to use
absolute_pointer to initialize it. The suffling is basically done in a
selective and careful way that the variable's scope doesn't matter being
local or global, for example, the global variable must not get modified
at run time throughout. For the record, here's the list of global
variables got shuffled in this patch.
grub-core/commands/i386/pc/drivemap.c::int13slot
grub-core/term/i386/pc/console.c::bios_data_area
grub-core/term/ns8250.c::serial_hw_io_addr
[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
[2]
https://elixir.bootlin.com/linux/v5.16.14/source/include/linux/compiler.h#L180
[3]
https://elixir.bootlin.com/linux/v5.16.14/source/include/linux/compiler-gcc.h#L31
Signed-off-by: Michael Chang
---
grub-core/bus/cs5536.c| 4 ++--
grub-core/commands/acpi.c | 4 ++--
grub-core/commands/efi/loadbios.c | 9 +
grub-core/commands/i386/pc/drivemap.c | 8 +---
grub-core/commands/i386/pc/sendkey.c | 12 ++--
grub-core/disk/i386/pc/biosdisk.c | 4 ++--
grub-core/fs/cbfs.c | 2 +-
grub-core/kern/i386/pc/acpi.c | 4 ++--
grub-core/kern/i386/pc/mmap.c | 2 +-
grub-core/loader/i386/multiboot_mbi.c | 2 +-
grub-core/loader/multiboot_mbi2.c | 4 ++--
grub-core/mmap/i386/pc/mmap.c | 26 +-
grub-core/net/drivers/i386/pc/pxe.c | 12 ++--
grub-core/term/i386/pc/console.c | 5 ++---
grub-core/term/i386/pc/vga_text.c | 6 +++---
grub-core/term/ns8250.c | 7 ++-
grub-core/video/i386/pc/vbe.c | 6 +++---
include/grub/types.h | 24
18 files changed, 86 insertions(+), 55 deletions(-)
diff --git a/grub-core/bus/cs5536.c b/grub-core/bus/cs5536.c
index 8c90ed598d..1e51f62606 100644
--- a/grub-core/bus/cs5536.c
+++ b/grub-core/bus/cs5536.c
@@ -331,8 +331,8 @@ grub_cs5536_init_geode (grub_pci_device_t dev)
{
volatile grub_uint32_t *oc;
-oc = grub_pci_device_map_range (dev, 0x05022000,
- GRUB_CS5536_USB_OPTION_REGS_SIZE);
+oc = grub_absolute_pointer (grub_pci_device_map_range (dev, 0x05022000,
+ GRUB_CS5536_USB_OPTION_REGS_SIZE));
oc[GRUB_CS5536_USB_OPTION_REG_UOCMUX] =
(oc[GRUB_CS5536_USB_OPTION_REG_UOCMUX]
diff --git a/grub-core/commands/acpi.c b/grub-core/commands/acpi.c
index 1215f2a62e..4721730b39 100644
--- a/grub-core/commands/acpi.c
+++ b/grub-core/commands/acpi.c
@@ -168,7 +168,7 @@ grub_acpi_create_ebda (void)
struct grub_acpi_rsdp_v10 *v1;
struct grub_acpi_rsdp_v20 *v2;
- ebda = (grub_uint8_t *) (grub_addr_t) ((*((grub_uint16_t *)0x40e)) << 4);
+ ebda = (grub_uint8_t *) (grub_addr_t) ((*((grub_uint16_t
*)grub_absolute_pointer(0x40e))) << 4);
grub_dprintf ("acpi", "EBDA @%p\n", ebda);
if (ebda)
ebda_kb_len = *(grub_uint16_t *) ebda;
@@ -298,7 +298,7 @@ grub_acpi_create_ebda (void)
*target = 0;
grub_dprintf ("acpi", "Switching EBDA\n");
- (*((grub_uint16_t *) 0x40e)) = ((grub_addr_t) targetebda) >> 4;
+ (*((grub_uint16_t *) grub_absolute_pointer(0x40e))) = ((grub_addr_t)
targetebda) >> 4;
grub_dprintf ("acpi", "EBDA switched\n");
return GRUB_ERR_NONE;
diff --git a/grub-core/commands/efi/loadbios.c
b/grub-core/commands/efi/loadbios.c
index 5c7725f8bd..574e410466 100644
--- a/grub-core/commands/efi/loadbios.c
+++ b/grub-core/commands/efi/loadbios.c
@@ -46,7 +46,7 @@
[PATCH v2 0/3] Fix GCC 12 build error
The tested gcc version is: abuild@mazu:~> gcc --version gcc (SUSE Linux) 12.0.1 20220307 (experimental) [revision 40c1d4a07e5798c01e4364336c9617550744861d] Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Although it may not catch all build errors as there are quite many combinations of cpu architecture and platform which grub supports. The work is as far as I can get right now and I'd like to have them reviewed before anyone running into similar problems. v2: Fix -Werror=array-bounds array subscript 0 is outside array bounds 1. Replace null with NULL in commit message 2. Add explain to do variable shuffling in commit message 3. Change macro grub_absolute_pointer definition to include/grub/types.h 4. Use grub_addr_t as pointer type in grub_absolute_pointer 5. Use asm keyword instead of __asm__ 6. Mention RELOC_HIDE() macro in the comment of grub_absolute_pointer Thanks, Michael Michael Chang (3): mkimage: Fix dangling pointer may be used error Fix -Werror=array-bounds array subscript 0 is outside array bounds reed_solomon: Fix array subscript 0 is outside array bounds grub-core/bus/cs5536.c| 4 ++-- grub-core/commands/acpi.c | 4 ++-- grub-core/commands/efi/loadbios.c | 9 + grub-core/commands/i386/pc/drivemap.c | 8 +--- grub-core/commands/i386/pc/sendkey.c | 12 ++-- grub-core/disk/i386/pc/biosdisk.c | 4 ++-- grub-core/fs/cbfs.c | 2 +- grub-core/kern/i386/pc/acpi.c | 4 ++-- grub-core/kern/i386/pc/mmap.c | 2 +- grub-core/lib/reed_solomon.c | 9 + grub-core/loader/i386/multiboot_mbi.c | 2 +- grub-core/loader/multiboot_mbi2.c | 4 ++-- grub-core/mmap/i386/pc/mmap.c | 26 +- grub-core/net/drivers/i386/pc/pxe.c | 12 ++-- grub-core/term/i386/pc/console.c | 5 ++--- grub-core/term/i386/pc/vga_text.c | 6 +++--- grub-core/term/ns8250.c | 7 ++- grub-core/video/i386/pc/vbe.c | 6 +++--- include/grub/types.h | 24 util/mkimage.c| 21 + 20 files changed, 116 insertions(+), 55 deletions(-) -- 2.34.1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 3/3] reed_solomon: Fix array subscript 0 is outside array bounds
The grub_absolute_pointer() is a compound expression that can only work
within a function. We are out of luck here when the pointer variables
require global definition due to ATTRIBUTE_TEXT that have to use fully
initialized global definition because of the way linkers work.
static gf_single_t * const gf_powx ATTRIBUTE_TEXT = (void *) 0x10;
For the reason given above, use gcc diagnostic pragmas to suppress the
array-bounds warning.
Signed-off-by: Michael Chang
Reviewed-by: Daniel Kiper
---
grub-core/lib/reed_solomon.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/grub-core/lib/reed_solomon.c b/grub-core/lib/reed_solomon.c
index 82779a296b..562bd2e3e3 100644
--- a/grub-core/lib/reed_solomon.c
+++ b/grub-core/lib/reed_solomon.c
@@ -102,6 +102,11 @@ static gf_single_t errvals[256];
static gf_single_t eqstat[65536 + 256];
#endif
+#if __GNUC__ == 12
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Warray-bounds"
+#endif
+
static gf_single_t
gf_mul (gf_single_t a, gf_single_t b)
{
@@ -319,6 +324,10 @@ decode_block (gf_single_t *ptr, grub_size_t s,
}
}
+#if __GNUC__ == 12
+#pragma GCC diagnostic pop
+#endif
+
#if !defined (STANDALONE)
static void
encode_block (gf_single_t *ptr, grub_size_t s,
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 1/3] mkimage: Fix dangling pointer may be used error
The warning is real as long as dangling pointer to 'tmp_' may be used if o32 and o64 are both null. However that is not going to happen and can be ignored safely because the PE_OHDR is being used in a context that either o32 or o64 must have been properly initialized. Sadly compiler seems not to always optimize that unused _tmp away so explicit suppression remain needed here. ../util/mkimage.c: In function 'grub_install_generate_image': ../util/mkimage.c:1422:41: error: dangling pointer to 'tmp_' may be used [-Werror=dangling-pointer=] 1422 | PE_OHDR (o32, o64, header_size) = grub_host_to_target32 (header_size); ../util/mkimage.c:857:28: note: 'tmp_' declared here 857 | __typeof__((o64)->field) tmp_;\ |^~~~ Signed-off-by: Michael Chang Reviewed-by: Daniel Kiper --- util/mkimage.c | 21 + 1 file changed, 21 insertions(+) diff --git a/util/mkimage.c b/util/mkimage.c index 21c2db7362..43078c71cd 100644 --- a/util/mkimage.c +++ b/util/mkimage.c @@ -1383,6 +1383,10 @@ grub_install_generate_image (const char *dir, const char *prefix, section = (struct grub_pe32_section_table *)(o64 + 1); } +#if __GNUC__ >= 12 +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wdangling-pointer" +#endif PE_OHDR (o32, o64, header_size) = grub_host_to_target32 (header_size); PE_OHDR (o32, o64, entry_addr) = grub_host_to_target32 (layout.start_address); PE_OHDR (o32, o64, image_base) = 0; @@ -1402,6 +1406,9 @@ grub_install_generate_image (const char *dir, const char *prefix, /* The sections. */ PE_OHDR (o32, o64, code_base) = grub_host_to_target32 (vma); PE_OHDR (o32, o64, code_size) = grub_host_to_target32 (layout.exec_size); +#if __GNUC__ >= 12 +#pragma GCC diagnostic pop +#endif section = init_pe_section (image_target, section, ".text", &vma, layout.exec_size, image_target->section_align, @@ -1411,10 +1418,17 @@ grub_install_generate_image (const char *dir, const char *prefix, GRUB_PE32_SCN_MEM_READ); scn_size = ALIGN_UP (layout.kernel_size - layout.exec_size, GRUB_PE32_FILE_ALIGNMENT); +#if __GNUC__ >= 12 +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wdangling-pointer" +#endif /* ALIGN_UP (sbat_size, GRUB_PE32_FILE_ALIGNMENT) is done earlier. */ PE_OHDR (o32, o64, data_size) = grub_host_to_target32 (scn_size + sbat_size + ALIGN_UP (total_module_size, GRUB_PE32_FILE_ALIGNMENT)); +#if __GNUC__ >= 12 +#pragma GCC diagnostic pop +#endif section = init_pe_section (image_target, section, ".data", &vma, scn_size, image_target->section_align, @@ -1445,8 +1459,15 @@ grub_install_generate_image (const char *dir, const char *prefix, } scn_size = layout.reloc_size; +#if __GNUC__ >= 12 +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wdangling-pointer" +#endif PE_OHDR (o32, o64, base_relocation_table.rva) = grub_host_to_target32 (vma); PE_OHDR (o32, o64, base_relocation_table.size) = grub_host_to_target32 (scn_size); +#if __GNUC__ >= 12 +#pragma GCC diagnostic pop +#endif memcpy (pe_img + raw_data, layout.reloc_section, scn_size); init_pe_section (image_target, section, ".reloc", &vma, scn_size, image_target->section_align, -- 2.34.1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/3] Fix -Werror=array-bounds array subscript 0 is outside array bounds
On Tue, Mar 22, 2022 at 10:19:26PM +0100, Daniel Kiper wrote:
> On Thu, Mar 17, 2022 at 02:43:41PM +0800, Michael Chang via Grub-devel wrote:
> > The grub is failing to build with gcc-12 in many places like this:
> >
> > In function 'init_cbfsdisk',
> > inlined from 'grub_mod_init' at ../../grub-core/fs/cbfs.c:391:3:
> > ../../grub-core/fs/cbfs.c:345:7: error: array subscript 0 is outside array
> > bounds of 'grub_uint32_t[0]' {aka 'unsigned int[]'} [-Werror=array-bounds]
> > 345 | ptr = *(grub_uint32_t *) 0xfffc;
> > | ^~~
> >
> > This is caused by gcc regression in 11/12 [1]. In a nut shell, the
> > warning is about detected invalid accesses at non-zero offsets to null
>
> May I ask you to be more consistent and use NULL instead of null everywhere?
Yes, no problem.
>
> > pointers. Since hardwired constant address is treated as NULL plus an
> > offset in the same underlying code, the warning is therefore triggered.
> >
> > Instead of inserting #pragma all over the places where literal pointers
> > are accessed to avoid diagnosing array-bounds, we can try to borrow the
> > idea from linux kernel that the absolute_pointer macro [2][3] is used to
> > disconnect a pointer using literal address from it's original object,
> > hence gcc won't be able to make assumptions on the boundary while doing
> > pointer arithmetic. With that we can greatly reduce the code we have to
> > cover up by making initial literal pointer assignment to use the new
> > wrapper but not having to track everywhere literal pointers are
> > accessed. This also makes code looks cleaner.
> >
> > [1]
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
> > [2]
> > https://elixir.bootlin.com/linux/v5.16.14/source/include/linux/compiler.h#L180
> > [3]
> > https://elixir.bootlin.com/linux/v5.16.14/source/include/linux/compiler-gcc.h#L31
> >
> > Signed-off-by: Michael Chang
>
> [...]
>
> > diff --git a/grub-core/commands/i386/pc/drivemap.c
> > b/grub-core/commands/i386/pc/drivemap.c
> > index 3fb22dc460..5e13f82eb5 100644
> > --- a/grub-core/commands/i386/pc/drivemap.c
> > +++ b/grub-core/commands/i386/pc/drivemap.c
> > @@ -31,9 +31,6 @@
> >
> > GRUB_MOD_LICENSE ("GPLv3+");
> >
> > -/* Real mode IVT slot (seg:off far pointer) for interrupt 0x13. */
> > -static grub_uint32_t *const int13slot = (grub_uint32_t *) (4 * 0x13);
> > -
> > /* Remember to update enum opt_idxs accordingly. */
> > static const struct grub_arg_option options[] = {
> >/* TRANSLATORS: In this file "mapping" refers to a change GRUB makes so
> > if
> > @@ -280,6 +277,9 @@ install_int13_handler (int noret __attribute__
> > ((unused)))
> >grub_uint8_t *handler_base = 0;
> >/* Address of the map within the deployed bundle. */
> >int13map_node_t *handler_map;
> > + /* Real mode IVT slot (seg:off far pointer) for interrupt 0x13. */
> > + grub_uint32_t *int13slot = (grub_uint32_t *) grub_absolute_pointer (4 *
> > 0x13);
>
> This shuffling looks strange and should be explained in the commit message.
> I understood what is going here when I took a look at patch #3.
Yes the shuffling was due to the same reasoning provided in patch 3.
I'll include it to flesh out in the commit message.
>
> > +
>
> Please drop this empty line addition.
OK.
>
> >int i;
> >int entries = 0;
> > @@ -354,6 +354,9 @@ install_int13_handler (int noret __attribute__
> > ((unused)))
> > static grub_err_t
> > uninstall_int13_handler (void)
> > {
> > + /* Real mode IVT slot (seg:off far pointer) for interrupt 0x13. */
> > + grub_uint32_t *int13slot = (grub_uint32_t *) grub_absolute_pointer (4 *
> > 0x13);
>
> WRT shuffling, ditto.
OK.
>
> > +
> >if (! grub_drivemap_oldhandler)
> > return GRUB_ERR_NONE;
>
> [...]
>
> > diff --git a/grub-core/term/i386/pc/console.c
> > b/grub-core/term/i386/pc/console.c
> > index d44937c305..9403390f1f 100644
> > --- a/grub-core/term/i386/pc/console.c
> > +++ b/grub-core/term/i386/pc/console.c
> > @@ -238,12 +238,11 @@ grub_console_getkey (struct grub_term_input *term
> > __attribute__ ((unused)))
> >return (regs.eax & 0xff) + (('a' - 1) | GRUB_TERM_CTRL);
> > }
> >
> > -static const struct grub_machine_bios_data_area *bios_data_area =
> > - (struct grub_machine_bios_data_area *)
> > GRUB_MEMORY_MACHINE_BIOS_DATA_
Re: [PATCH v2 5/5] util/grub-protect: Add new tool
On Tue, Feb 01, 2022 at 05:02:57AM -0800, Hernan Gatta wrote:
[snip]
> +static grub_err_t
> +grub_protect_tpm2_get_policy_digest (struct grub_protect_args *args,
> + TPM2B_DIGEST *digest)
> +{
[snip]
> + for (i = 0; i < args->tpm2_pcr_count; i++)
> +{
> + if (pcr_values.digests[i].size != pcr_digest_len)
> +{
> + fprintf (stderr,
> + _("Bad PCR value size: expected %lu bytes but got %u
> bytes.\n"),
> + pcr_digest_len, pcr_values.digests[i].size);
Again please consider to use PRI[uxd]GRUB_.* for the conversion
specifier, otherwise i386-efi will not build.
Thanks,
Michael
> + goto exit2;
> +}
> +
> + grub_memcpy (pcr_cursor, pcr_values.digests[i].buffer, pcr_digest_len);
> + pcr_cursor += pcr_digest_len;
> +}
> +
> + grub_crypto_hash (hash_spec, pcr_digest, pcr_concat, pcr_concat_len);
> +
> + /* Start Trial Session */
> + nonce.size = TPM_SHA256_DIGEST_SIZE;
> + symmetric.algorithm = TPM_ALG_NULL;
> +
> + rc = TPM2_StartAuthSession (TPM_RH_NULL, TPM_RH_NULL, 0, &nonce, &salt,
> + TPM_SE_TRIAL, &symmetric, TPM_ALG_SHA256,
> + &session, NULL, 0);
> + if (rc != TPM_RC_SUCCESS)
> +{
> + fprintf (stderr,
> + _("Failed to start trial policy session (TPM error:
> 0x%x).\n"),
> + rc);
> + err = GRUB_ERR_BAD_DEVICE;
> + goto exit2;
> +}
> +
> + /* PCR Policy */
> + memcpy (pcr_digest_in.buffer, pcr_digest, TPM_SHA256_DIGEST_SIZE);
> +
> + rc = TPM2_PolicyPCR (session, NULL, &pcr_digest_in, &pcr_sel, NULL);
> + if (rc != TPM_RC_SUCCESS)
> +{
> + fprintf (stderr, _("Failed to submit PCR policy (TPM error: 0x%x).\n"),
> + rc);
> + err = GRUB_ERR_BAD_DEVICE;
> + goto exit3;
> +}
> +
> + /* Retrieve Policy Digest */
> + rc = TPM2_PolicyGetDigest (session, NULL, &policy_digest, NULL);
> + if (rc != TPM_RC_SUCCESS)
> +{
> + fprintf (stderr, _("Failed to get policy digest (TPM error: 0x%x).\n"),
> + rc);
> + err = GRUB_ERR_BAD_DEVICE;
> + goto exit3;
> +}
> +
> + /* Epilogue */
> + *digest = policy_digest;
> + err = GRUB_ERR_NONE;
> +
> +exit3:
> + TPM2_FlushContext (session);
> +
> +exit2:
> + grub_free (pcr_concat);
> +
> +exit1:
> + grub_free (pcr_digest);
> +
> + return err;
> +}
> +
> +static grub_err_t
> +grub_protect_tpm2_get_srk (struct grub_protect_args *args, TPM_HANDLE *srk)
> +{
> + TPM_RC rc;
> + TPM2B_PUBLIC public;
> + TPMS_AUTH_COMMAND authCommand = { 0 };
> + TPM2B_SENSITIVE_CREATE inSensitive = { 0 };
> + TPM2B_PUBLIC inPublic = { 0 };
> + TPM2B_DATA outsideInfo = { 0 };
> + TPML_PCR_SELECTION creationPcr = { 0 };
> + TPM2B_PUBLIC outPublic = { 0 };
> + TPM2B_CREATION_DATA creationData = { 0 };
> + TPM2B_DIGEST creationHash = { 0 };
> + TPMT_TK_CREATION creationTicket = { 0 };
> + TPM2B_NAME srkName = { 0 };
> + TPM_HANDLE srkHandle;
> +
> + /* Find SRK */
> + rc = TPM2_ReadPublic (args->tpm2_srk, NULL, &public);
> + if (rc == TPM_RC_SUCCESS)
> +{
> + if (args->tpm2_persist)
> +fprintf (stderr,
> + _("Warning: --tpm2-persist was specified but the SRK
> already "
> + "exists on the TPM. Continuing anyway...\n"));
> +
> + *srk = TPM2_SRK_HANDLE;
> + return GRUB_ERR_NONE;
> +}
> +
> + /* The handle exists but its public area could not be read. */
> + if ((rc & ~TPM_RC_N_MASK) != TPM_RC_HANDLE)
> +{
> + fprintf (stderr,
> + _("The SRK exists on the TPM but its public area cannot be
> read "
> + "(TPM error: 0x%x).\n"), rc);
> + return GRUB_ERR_BAD_DEVICE;
> +}
> +
> + /* Create SRK */
> + authCommand.sessionHandle = TPM_RS_PW;
> + inPublic.publicArea.type = args->tpm2_asymmetric;
> + inPublic.publicArea.nameAlg = TPM_ALG_SHA256;
> + inPublic.publicArea.objectAttributes.restricted = 1;
> + inPublic.publicArea.objectAttributes.userWithAuth = 1;
> + inPublic.publicArea.objectAttributes.decrypt = 1;
> + inPublic.publicArea.objectAttributes.fixedTPM = 1;
> + inPublic.publicArea.objectAttributes.fixedParent = 1;
> + inPublic.publicArea.objectAttributes.sensitiveDataOrigin = 1;
> + inPublic.publicArea.objectAttributes.noDA = 1;
> +
> + switch (args->tpm2_asymmetric)
> +{
> +case TPM_ALG_RSA:
> + inPublic.publicArea.parameters.rsaDetail.symmetric.algorithm =
> TPM_ALG_AES;
> + inPublic.publicArea.parameters.rsaDetail.symmetric.keyBits.aes = 128;
> + inPublic.publicArea.parameters.rsaDetail.symmetric.mode.aes =
> TPM_ALG_CFB;
> + inPublic.publicArea.parameters.rsaDetail.scheme.scheme = TPM_ALG_NULL;
> + inPublic.publicArea.parameters.rsaDetail.keyBits = 2048;
> + inPublic.publicArea.parameters.rsaDetail.exponent = 0;
> + break;
> +
> +case TPM_ALG_ECC:
> + inPublic.publicArea.parameters
Re: [PATCH v2 3/5] protectors: Add TPM2 Key Protector
On Tue, Feb 01, 2022 at 05:02:55AM -0800, Hernan Gatta wrote:
Sorry forgot to mention another build related issue in previous reply.
> +static grub_err_t
> +grub_tpm2_protector_srk_unmarshal_keyfile (void *sealed_key,
> + grub_size_t sealed_key_size,
> + TPM2_SEALED_KEY *sk)
> +{
> + struct grub_tpm2_buffer buf;
> +
> + grub_tpm2_buffer_init (&buf);
> + if (sealed_key_size > buf.cap)
> +{
> + grub_dprintf ("tpm2", "Sealed key file is larger than decode buffer "
> +"(%lu vs %lu bytes).\n", sealed_key_size,
> buf.cap);
This fails in i386-efi build with:
../../grub-core/tpm2/module.c: In function
'grub_tpm2_protector_srk_unmarshal_keyfile':
../../grub-core/tpm2/module.c:197:29: error: format '%lu' expects argument of
type 'long unsigned int', but argument 5 has type 'grub_size_t' {aka 'unsigned
int'} [-Werror=format=]
197 | grub_dprintf ("tpm2", "Sealed key file is larger than decode
buffer "
|
^~~
198 | "(%lu vs %lu bytes).\n", sealed_key_size,
buf.cap);
| ~~~
| |
| grub_size_t {aka
unsigned int}
Maybe it's better to use generalized PRI[uxd]GRUB_.* macro defined in
grub/types.h than lu to deal with platform dependent conversion
specifiers.
Thanks,
Michael
> + return GRUB_ERR_BAD_ARGUMENT;
> +}
> +
> + grub_memcpy (buf.data, sealed_key, sealed_key_size);
> + buf.size = sealed_key_size;
> +
> + grub_tpm2_mu_TPM2B_PUBLIC_Unmarshal (&buf, &sk->public);
> + grub_tpm2_mu_TPM2B_Unmarshal (&buf, (TPM2B *)&sk->private);
> +
> + if (buf.error)
> +{
> + grub_dprintf ("tpm2", "Could not unmarshal sealed key file, it is
> likely "
> +"malformed.\n");
> + return GRUB_ERR_BAD_ARGUMENT;
> +}
> +
> + return GRUB_ERR_NONE;
> +}
> +
> +static grub_err_t
> +grub_tpm2_protector_srk_get (const struct grub_tpm2_protector_context *ctx,
> + TPM_HANDLE *srk)
> +{
> + TPM_RC rc;
> + TPM2B_PUBLIC public;
> + TPMS_AUTH_COMMAND authCommand = { 0 };
> + TPM2B_SENSITIVE_CREATE inSensitive = { 0 };
> + TPM2B_PUBLIC inPublic = { 0 };
> + TPM2B_DATA outsideInfo = { 0 };
> + TPML_PCR_SELECTION creationPcr = { 0 };
> + TPM2B_PUBLIC outPublic = { 0 };
> + TPM2B_CREATION_DATA creationData = { 0 };
> + TPM2B_DIGEST creationHash = { 0 };
> + TPMT_TK_CREATION creationTicket = { 0 };
> + TPM2B_NAME srkName = { 0 };
> + TPM_HANDLE srkHandle;
> +
> + /* Find SRK */
> + rc = TPM2_ReadPublic (ctx->srk, NULL, &public);
> + if (rc == TPM_RC_SUCCESS)
> +{
> + *srk = ctx->srk;
> + return GRUB_ERR_NONE;
> +}
> +
> + /* The handle exists but its public area could not be read. */
> + if ((rc & ~TPM_RC_N_MASK) != TPM_RC_HANDLE)
> +{
> + grub_dprintf ("tpm2", "The SRK handle (0x%x) exists on the TPM but its
> "
> +"public area could not be read (TPM2_ReadPublic "
> +"failed with TSS/TPM error %u).\n", ctx->srk,
> rc);
> + return GRUB_ERR_BAD_DEVICE;
> +}
> +
> + /* Create SRK */
> + authCommand.sessionHandle = TPM_RS_PW;
> + inPublic.publicArea.type = ctx->asymmetric;
> + inPublic.publicArea.nameAlg = TPM_ALG_SHA256;
> + inPublic.publicArea.objectAttributes.restricted = 1;
> + inPublic.publicArea.objectAttributes.userWithAuth = 1;
> + inPublic.publicArea.objectAttributes.decrypt = 1;
> + inPublic.publicArea.objectAttributes.fixedTPM = 1;
> + inPublic.publicArea.objectAttributes.fixedParent = 1;
> + inPublic.publicArea.objectAttributes.sensitiveDataOrigin = 1;
> + inPublic.publicArea.objectAttributes.noDA = 1;
> +
> + if (ctx->asymmetric == TPM_ALG_RSA)
> +{
> + inPublic.publicArea.parameters.rsaDetail.symmetric.algorithm =
> TPM_ALG_AES;
> + inPublic.publicArea.parameters.rsaDetail.symmetric.keyBits.aes = 128;
> + inPublic.publicArea.parameters.rsaDetail.symmetric.mode.aes =
> TPM_ALG_CFB;
> + inPublic.publicArea.parameters.rsaDetail.scheme.scheme = TPM_ALG_NULL;
> + inPublic.publicArea.parameters.rsaDetail.keyBits = 2048;
> + inPublic.publicArea.parameters.rsaDetail.exponent = 0;
> +}
> + else if (ctx->asymmetric == TPM_ALG_ECC)
> +{
> + inPublic.publicArea.parameters.eccDetail.symmetric.algorithm =
> TPM_ALG_AES;
> + inPublic.publicArea.parameters.eccDetail.symmetric.keyBits.aes = 128;
> + inPublic.publicArea.parameters.eccDetail.symmetric.mode.aes =
> TPM_ALG_CFB;
> + inPublic.publicArea.parameters.eccDetail.scheme.scheme = TPM_ALG_NULL;
> + inPublic.publicArea.parameters.eccDetail.curveID = TPM_ECC_NIST_P256;
> + inPublic.publicArea.par
Re: [PATCH v2 3/5] protectors: Add TPM2 Key Protector
On Tue, Feb 01, 2022 at 05:02:55AM -0800, Hernan Gatta wrote:
> The TPM2 key protector is a module that enables the automatic retrieval of a
> fully-encrypted disk's unlocking key from a TPM 2.0.
>
> The theory of operation is such that the module accepts various arguments,
> most
> of which are optional and therefore possess reasonable defaults. One of these
> arguments is the keyfile parameter, which is mandatory.
>
> The value of this parameter must be a path to a sealed key file (e.g.,
> (hd0,gpt1)/boot/grub2/sealed_key). This sealed key file is created via the
> grub-protect tool. The tool utilizes the TPM's sealing functionality to seal
> (i.e., encrypt) an unlocking key using a Storage Root Key (SRK) to the values
> of
> various Platform Configuration Registers (PCRs). These PCRs reflect the state
> of
> the system as it boots. If the values are as expected, the system may be
> considered trustworthy, at which point the TPM allows for a caller to utilize
> the private component of the SRK to unseal (i.e., decrypt) the sealed key
> file.
> The caller, in this case, is this key protector.
>
> The TPM2 key protector registers two commands:
>
> - tpm2_key_protector_init: Initializes the state of the TPM2 key protector for
>later usage, clearing any previous state, too, if
>any.
>
> - tpm2_key_protector_clear: Clears any state set by tpm2_key_protector_init.
>
> The way this is expected to be used requires the user to, either interactively
> or, normally, via a boot script, initialize (i.e., configure) the key
> protector
> and then specify that it be used by the cryptomount command (modifications to
> this command are in a different patch).
>
> For instance:
>
> tpm2_key_protector_init --keyfile=KEYFILE1
> cryptomount DISK1 -k tpm2
>
> tpm2_key_protector_init --keyfile=KEYFILE2 --pcrs=7,11
> cryptomount DISK2 -k tpm2
>
> If a user does not initialize the key protector and attempts to use it anyway,
> the protector returns an error.
>
> Signed-off-by: Hernan Gatta
> ---
> grub-core/Makefile.core.def | 10 +
> grub-core/tpm2/args.c | 129 +++
> grub-core/tpm2/module.c | 710
> ++
> include/grub/tpm2/internal/args.h | 39 +++
> 4 files changed, 888 insertions(+)
> create mode 100644 grub-core/tpm2/args.c
> create mode 100644 grub-core/tpm2/module.c
> create mode 100644 include/grub/tpm2/internal/args.h
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index e4ae78b..78d09d9 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -2498,6 +2498,16 @@ module = {
> };
>
> module = {
> + name = tpm2;
> + common = tpm2/args.c;
> + common = tpm2/buffer.c;
> + common = tpm2/module.c;
> + common = tpm2/mu.c;
> + common = tpm2/tpm2.c;
> + efi = tpm2/tcg2.c;
The tpm2 module fails to build on non-efi platforms because of undefined
symbols from tpm2/tcg2.c. Maybe adding enable = efi is required here as
long as supporting other platform seems not to be intended.
Thanks,
Michael
> +};
> +
> +module = {
>name = tr;
>common = commands/tr.c;
> };
> diff --git a/grub-core/tpm2/args.c b/grub-core/tpm2/args.c
> new file mode 100644
> index 000..90c7cd8
> --- /dev/null
> +++ b/grub-core/tpm2/args.c
> @@ -0,0 +1,129 @@
> +/*
> + * GRUB -- GRand Unified Bootloader
> + * Copyright (C) 2022 Microsoft Corporation
> + *
> + * GRUB is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation, either version 3 of the License, or
> + * (at your option) any later version.
> + *
> + * GRUB is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with GRUB. If not, see
Re: [PATCH 3/3] reed_solomon: Fix array subscript 0 is outside array bounds
On Thu, Mar 17, 2022 at 08:41:32AM +0100, Paul Menzel wrote:
> Dear Michael,
>
>
> Thank you for working on that.
>
>
> Am 17.03.22 um 07:43 schrieb Michael Chang via Grub-devel:
> > The grub_absolute_pointer() is a compound expression that can only work
> > within a function. We are out of luck here when the pointer variables
> > require global definition due to ATTRIBUTE_TEXT that have to use fully
> > initialized global definition because of the way linkers work.
> >
> > static gf_single_t * const gf_powx ATTRIBUTE_TEXT = (void *) 0x10;
> >
> > For the reason given above, use gcc diagnostic pragmas to suppress the
> > array-bounds warning.
>
> Can you please share the exact GCC warning messages?
Yes. It is very long so I didn't put in the description:
[ 184s] ../../grub-core/lib/reed_solomon.c: In function 'pol_evaluate':
[ 184s] ../../grub-core/lib/reed_solomon.c:147:39: error: array subscript [1,
255] is outside array bounds of 'gf_single_t[0]' {aka 'unsigned char[]'}
[-Werror=array-bounds]
[ 184s] 147 | s ^= gf_powx[(int) gf_powx_inv[pol[i]] + log_xn];
[ 184s] |~~~^~~~
[ 184s] ../../grub-core/lib/reed_solomon.c:147:21: error: array subscript [0,
2147483647] is outside array bounds of 'gf_single_t[0]' {aka 'unsigned char[]'}
[-Werror=array-bounds]
[ 184s] 147 | s ^= gf_powx[(int) gf_powx_inv[pol[i]] + log_xn];
[ 184s] | ~~~^~~~
[ 184s] In function 'gf_mul',
[ 184s] inlined from 'gf_mul' at ../../grub-core/lib/reed_solomon.c:106:1:
[ 184s] ../../grub-core/lib/reed_solomon.c:110:35: error: array subscript [1,
255] is outside array bounds of 'gf_single_t[0]' {aka 'unsigned char[]'}
[-Werror=array-bounds]
[ 184s] 110 | return gf_powx[(int) gf_powx_inv[a] + (int) gf_powx_inv[b]];
[ 184s] |~~~^~~
[ 184s] ../../grub-core/lib/reed_solomon.c:110:58: error: array subscript [1,
255] is outside array bounds of 'gf_single_t[0]' {aka 'unsigned char[]'}
[-Werror=array-bounds]
[ 184s] 110 | return gf_powx[(int) gf_powx_inv[a] + (int) gf_powx_inv[b]];
[ 184s] | ~~~^~~
[ 184s] ../../grub-core/lib/reed_solomon.c:110:17: error: array subscript 0 is
outside array bounds of 'gf_single_t[0]' {aka 'unsigned char[]'}
[-Werror=array-bounds]
[ 184s] 110 | return gf_powx[(int) gf_powx_inv[a] + (int) gf_powx_inv[b]];
[ 184s] | ~~~^
[ 184s] ../../grub-core/lib/reed_solomon.c: In function
'gauss_solve.constprop':
[ 184s] ../../grub-core/lib/reed_solomon.c:231:21: error: array subscript 0 is
outside array bounds of 'int[0]' [-Werror=array-bounds]
[ 184s] 231 | if (chosenstat[i] == -1)
[ 184s] | ~~^~~
[ 184s] ../../grub-core/lib/reed_solomon.c:235:14: error: array subscript [0,
2147483647] is outside array bounds of 'gf_single_t[0]' {aka 'unsigned char[]'}
[-Werror=array-bounds]
[ 184s] 235 | s ^= eq[i * (m + 1) + m];
[ 184s] |~~^
[ 184s] ../../grub-core/lib/reed_solomon.c:234:24: error: array subscript 0 is
outside array bounds of 'gf_single_t[0]' {aka 'unsigned char[]'}
[-Werror=array-bounds]
[ 184s] 234 | s ^= gf_mul (eq[i * (m + 1) + j], sol[j]);
[ 184s] | ~~^
[ 184s] In function 'gauss_eliminate',
[ 184s] inlined from 'gauss_solve.constprop' at
../../grub-core/lib/reed_solomon.c:227:3:
[ 184s] ../../grub-core/lib/reed_solomon.c:201:39: error: array subscript 0 is
outside array bounds of 'gf_single_t[0]' {aka 'unsigned char[]'}
[-Werror=array-bounds]
[ 184s] 201 | for (nzidx = 0; nzidx < m && (eq[i * (m + 1) + nzidx] ==
0);
[ 184s] | ~~^
[ 184s] ../../grub-core/lib/reed_solomon.c:205:17: error: array subscript 0 is
outside array bounds of 'int[0]' [-Werror=array-bounds]
[ 184s] 205 | chosen[i] = nzidx;
[ 184s] | ~~^~~
[ 184s] ../../grub-core/lib/reed_solomon.c:206:24: error: array subscript [0,
2147483647] is outside array bounds of 'gf_single_t[0]' {aka 'unsigned char[]'}
[-Werror=array-bounds]
[ 184s] 206 | r = gf_invert (eq[i * (m + 1) + nzidx]);
[ 184s] | ~~^
[ 184s] In function 'gf_invert',
[ 184s] inlined from 'gauss_eliminate' at
../../grub-core/lib/reed_solomon.c:206:11,
[ 184s] inlined
[PATCH 3/3] reed_solomon: Fix array subscript 0 is outside array bounds
The grub_absolute_pointer() is a compound expression that can only work
within a function. We are out of luck here when the pointer variables
require global definition due to ATTRIBUTE_TEXT that have to use fully
initialized global definition because of the way linkers work.
static gf_single_t * const gf_powx ATTRIBUTE_TEXT = (void *) 0x10;
For the reason given above, use gcc diagnostic pragmas to suppress the
array-bounds warning.
Signed-off-by: Michael Chang
---
grub-core/lib/reed_solomon.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/grub-core/lib/reed_solomon.c b/grub-core/lib/reed_solomon.c
index 82779a296b..562bd2e3e3 100644
--- a/grub-core/lib/reed_solomon.c
+++ b/grub-core/lib/reed_solomon.c
@@ -102,6 +102,11 @@ static gf_single_t errvals[256];
static gf_single_t eqstat[65536 + 256];
#endif
+#if __GNUC__ == 12
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Warray-bounds"
+#endif
+
static gf_single_t
gf_mul (gf_single_t a, gf_single_t b)
{
@@ -319,6 +324,10 @@ decode_block (gf_single_t *ptr, grub_size_t s,
}
}
+#if __GNUC__ == 12
+#pragma GCC diagnostic pop
+#endif
+
#if !defined (STANDALONE)
static void
encode_block (gf_single_t *ptr, grub_size_t s,
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 2/3] Fix -Werror=array-bounds array subscript 0 is outside array bounds
The grub is failing to build with gcc-12 in many places like this:
In function 'init_cbfsdisk',
inlined from 'grub_mod_init' at ../../grub-core/fs/cbfs.c:391:3:
../../grub-core/fs/cbfs.c:345:7: error: array subscript 0 is outside array
bounds of 'grub_uint32_t[0]' {aka 'unsigned int[]'} [-Werror=array-bounds]
345 | ptr = *(grub_uint32_t *) 0xfffc;
| ^~~
This is caused by gcc regression in 11/12 [1]. In a nut shell, the
warning is about detected invalid accesses at non-zero offsets to null
pointers. Since hardwired constant address is treated as NULL plus an
offset in the same underlying code, the warning is therefore triggered.
Instead of inserting #pragma all over the places where literal pointers
are accessed to avoid diagnosing array-bounds, we can try to borrow the
idea from linux kernel that the absolute_pointer macro [2][3] is used to
disconnect a pointer using literal address from it's original object,
hence gcc won't be able to make assumptions on the boundary while doing
pointer arithmetic. With that we can greatly reduce the code we have to
cover up by making initial literal pointer assignment to use the new
wrapper but not having to track everywhere literal pointers are
accessed. This also makes code looks cleaner.
[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
[2]
https://elixir.bootlin.com/linux/v5.16.14/source/include/linux/compiler.h#L180
[3]
https://elixir.bootlin.com/linux/v5.16.14/source/include/linux/compiler-gcc.h#L31
Signed-off-by: Michael Chang
---
grub-core/bus/cs5536.c| 4 ++--
grub-core/commands/acpi.c | 4 ++--
grub-core/commands/efi/loadbios.c | 9 +
grub-core/commands/i386/pc/drivemap.c | 9 ++---
grub-core/commands/i386/pc/sendkey.c | 12 ++--
grub-core/disk/i386/pc/biosdisk.c | 4 ++--
grub-core/fs/cbfs.c | 2 +-
grub-core/kern/i386/pc/acpi.c | 4 ++--
grub-core/kern/i386/pc/mmap.c | 2 +-
grub-core/loader/i386/multiboot_mbi.c | 2 +-
grub-core/loader/multiboot_mbi2.c | 4 ++--
grub-core/mmap/i386/pc/mmap.c | 26 +-
grub-core/net/drivers/i386/pc/pxe.c | 12 ++--
grub-core/term/i386/pc/console.c | 5 ++---
grub-core/term/i386/pc/vga_text.c | 6 +++---
grub-core/term/ns8250.c | 7 ++-
grub-core/video/i386/pc/vbe.c | 6 +++---
include/grub/compiler.h | 11 +++
18 files changed, 74 insertions(+), 55 deletions(-)
diff --git a/grub-core/bus/cs5536.c b/grub-core/bus/cs5536.c
index 8c90ed598d..1e51f62606 100644
--- a/grub-core/bus/cs5536.c
+++ b/grub-core/bus/cs5536.c
@@ -331,8 +331,8 @@ grub_cs5536_init_geode (grub_pci_device_t dev)
{
volatile grub_uint32_t *oc;
-oc = grub_pci_device_map_range (dev, 0x05022000,
- GRUB_CS5536_USB_OPTION_REGS_SIZE);
+oc = grub_absolute_pointer (grub_pci_device_map_range (dev, 0x05022000,
+ GRUB_CS5536_USB_OPTION_REGS_SIZE));
oc[GRUB_CS5536_USB_OPTION_REG_UOCMUX] =
(oc[GRUB_CS5536_USB_OPTION_REG_UOCMUX]
diff --git a/grub-core/commands/acpi.c b/grub-core/commands/acpi.c
index 1215f2a62e..4721730b39 100644
--- a/grub-core/commands/acpi.c
+++ b/grub-core/commands/acpi.c
@@ -168,7 +168,7 @@ grub_acpi_create_ebda (void)
struct grub_acpi_rsdp_v10 *v1;
struct grub_acpi_rsdp_v20 *v2;
- ebda = (grub_uint8_t *) (grub_addr_t) ((*((grub_uint16_t *)0x40e)) << 4);
+ ebda = (grub_uint8_t *) (grub_addr_t) ((*((grub_uint16_t
*)grub_absolute_pointer(0x40e))) << 4);
grub_dprintf ("acpi", "EBDA @%p\n", ebda);
if (ebda)
ebda_kb_len = *(grub_uint16_t *) ebda;
@@ -298,7 +298,7 @@ grub_acpi_create_ebda (void)
*target = 0;
grub_dprintf ("acpi", "Switching EBDA\n");
- (*((grub_uint16_t *) 0x40e)) = ((grub_addr_t) targetebda) >> 4;
+ (*((grub_uint16_t *) grub_absolute_pointer(0x40e))) = ((grub_addr_t)
targetebda) >> 4;
grub_dprintf ("acpi", "EBDA switched\n");
return GRUB_ERR_NONE;
diff --git a/grub-core/commands/efi/loadbios.c
b/grub-core/commands/efi/loadbios.c
index 5c7725f8bd..574e410466 100644
--- a/grub-core/commands/efi/loadbios.c
+++ b/grub-core/commands/efi/loadbios.c
@@ -46,7 +46,7 @@ enable_rom_area (void)
grub_uint32_t *rom_ptr;
grub_pci_device_t dev = { .bus = 0, .device = 0, .function = 0};
- rom_ptr = (grub_uint32_t *) VBIOS_ADDR;
+ rom_ptr = grub_absolute_pointer (VBIOS_ADDR);
if (*rom_ptr != BLANK_MEM)
{
grub_puts_ (N_("ROM image is present."));
@@ -96,8 +96,8 @@ fake_bios_data (int use_rom)
void *acpi, *smbios;
grub_uint16_t *ebda_seg_ptr, *low_mem_ptr;
- ebda_seg_ptr = (grub_uint16_t *) EBDA_SEG_ADDR;
- low_mem_ptr = (grub_uint16_t *) LOW_MEM_ADDR;
+ ebda_seg_ptr = grub_absolute_pointer (EBDA_SEG_ADDR);
+ low_mem_ptr = grub_absolute_pointer (LOW_MEM_ADDR);
if ((*ebda_seg_ptr) || (*low_mem_ptr))
return;
[PATCH 1/3] mkimage: Fix dangling pointer may be used error
The warning is real as long as dangling pointer to 'tmp_' may be used if o32 and o64 are both null. However that is not going to happen and can be ignored safely because the PE_OHDR is being used in a context that either o32 or o64 must have been properly initialized. Sadly compiler seems not to always optimize that unused _tmp away so explicit suppression remain needed here. ../util/mkimage.c: In function 'grub_install_generate_image': ../util/mkimage.c:1422:41: error: dangling pointer to 'tmp_' may be used [-Werror=dangling-pointer=] 1422 | PE_OHDR (o32, o64, header_size) = grub_host_to_target32 (header_size); ../util/mkimage.c:857:28: note: 'tmp_' declared here 857 | __typeof__((o64)->field) tmp_;\ |^~~~ Signed-off-by: Michael Chang --- util/mkimage.c | 21 + 1 file changed, 21 insertions(+) diff --git a/util/mkimage.c b/util/mkimage.c index 21c2db7362..43078c71cd 100644 --- a/util/mkimage.c +++ b/util/mkimage.c @@ -1383,6 +1383,10 @@ grub_install_generate_image (const char *dir, const char *prefix, section = (struct grub_pe32_section_table *)(o64 + 1); } +#if __GNUC__ >= 12 +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wdangling-pointer" +#endif PE_OHDR (o32, o64, header_size) = grub_host_to_target32 (header_size); PE_OHDR (o32, o64, entry_addr) = grub_host_to_target32 (layout.start_address); PE_OHDR (o32, o64, image_base) = 0; @@ -1402,6 +1406,9 @@ grub_install_generate_image (const char *dir, const char *prefix, /* The sections. */ PE_OHDR (o32, o64, code_base) = grub_host_to_target32 (vma); PE_OHDR (o32, o64, code_size) = grub_host_to_target32 (layout.exec_size); +#if __GNUC__ >= 12 +#pragma GCC diagnostic pop +#endif section = init_pe_section (image_target, section, ".text", &vma, layout.exec_size, image_target->section_align, @@ -1411,10 +1418,17 @@ grub_install_generate_image (const char *dir, const char *prefix, GRUB_PE32_SCN_MEM_READ); scn_size = ALIGN_UP (layout.kernel_size - layout.exec_size, GRUB_PE32_FILE_ALIGNMENT); +#if __GNUC__ >= 12 +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wdangling-pointer" +#endif /* ALIGN_UP (sbat_size, GRUB_PE32_FILE_ALIGNMENT) is done earlier. */ PE_OHDR (o32, o64, data_size) = grub_host_to_target32 (scn_size + sbat_size + ALIGN_UP (total_module_size, GRUB_PE32_FILE_ALIGNMENT)); +#if __GNUC__ >= 12 +#pragma GCC diagnostic pop +#endif section = init_pe_section (image_target, section, ".data", &vma, scn_size, image_target->section_align, @@ -1445,8 +1459,15 @@ grub_install_generate_image (const char *dir, const char *prefix, } scn_size = layout.reloc_size; +#if __GNUC__ >= 12 +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wdangling-pointer" +#endif PE_OHDR (o32, o64, base_relocation_table.rva) = grub_host_to_target32 (vma); PE_OHDR (o32, o64, base_relocation_table.size) = grub_host_to_target32 (scn_size); +#if __GNUC__ >= 12 +#pragma GCC diagnostic pop +#endif memcpy (pe_img + raw_data, layout.reloc_section, scn_size); init_pe_section (image_target, section, ".reloc", &vma, scn_size, image_target->section_align, -- 2.34.1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 0/3] Fix GCC 12 build error
The tested gcc version is: abuild@mazu:~> gcc --version gcc (SUSE Linux) 12.0.1 20220307 (experimental) [revision 40c1d4a07e5798c01e4364336c9617550744861d] Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Although it may not catch all build errors as there are quite many combinations of cpu architecture and platform which grub supports. The work is as far as I can get right now and I'd like to have them reviewed before anyone running into similar problems. Thanks, Michael Michael Chang (3): mkimage: Fix dangling pointer may be used error Fix -Werror=array-bounds array subscript 0 is outside array bounds reed_solomon: Fix array subscript 0 is outside array bounds grub-core/bus/cs5536.c| 4 ++-- grub-core/commands/acpi.c | 4 ++-- grub-core/commands/efi/loadbios.c | 9 + grub-core/commands/i386/pc/drivemap.c | 9 ++--- grub-core/commands/i386/pc/sendkey.c | 12 ++-- grub-core/disk/i386/pc/biosdisk.c | 4 ++-- grub-core/fs/cbfs.c | 2 +- grub-core/kern/i386/pc/acpi.c | 4 ++-- grub-core/kern/i386/pc/mmap.c | 2 +- grub-core/lib/reed_solomon.c | 9 + grub-core/loader/i386/multiboot_mbi.c | 2 +- grub-core/loader/multiboot_mbi2.c | 4 ++-- grub-core/mmap/i386/pc/mmap.c | 26 +- grub-core/net/drivers/i386/pc/pxe.c | 12 ++-- grub-core/term/i386/pc/console.c | 5 ++--- grub-core/term/i386/pc/vga_text.c | 6 +++--- grub-core/term/ns8250.c | 7 ++- grub-core/video/i386/pc/vbe.c | 6 +++--- include/grub/compiler.h | 11 +++ util/mkimage.c| 21 + 20 files changed, 104 insertions(+), 55 deletions(-) -- 2.34.1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 3/6] commands/i386/pc/sendkey: Fix "writing 1 byte into a region of size 0" build error
On Fri, Mar 11, 2022 at 12:35:57AM +0100, Daniel Kiper wrote:
> Latest GCC may complain in that way:
>
> commands/i386/pc/sendkey.c: In function ‘grub_sendkey_postboot’:
> commands/i386/pc/sendkey.c:223:21: error: writing 1 byte into a region of
> size 0 [-Werror=stringop-overflow=]
> 223 | *((char *) 0x41a) = 0x1e;
> | ~~^~
>
> The volatile keyword addition helps and additionally assures us the
> compiler will not optimize out fixed assignments.
>
> Signed-off-by: Daniel Kiper
> ---
> grub-core/commands/i386/pc/sendkey.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/grub-core/commands/i386/pc/sendkey.c
> b/grub-core/commands/i386/pc/sendkey.c
> index 26d9acd3d..ab4bca9e9 100644
> --- a/grub-core/commands/i386/pc/sendkey.c
> +++ b/grub-core/commands/i386/pc/sendkey.c
> @@ -220,8 +220,8 @@ grub_sendkey_postboot (void)
>
>*flags = oldflags;
>
> - *((char *) 0x41a) = 0x1e;
> - *((char *) 0x41c) = 0x1e;
> + *((volatile char *) 0x41a) = 0x1e;
> + *((volatile char *) 0x41c) = 0x1e;
>
>return GRUB_ERR_NONE;
> }
> @@ -236,8 +236,8 @@ grub_sendkey_preboot (int noret __attribute__ ((unused)))
>oldflags = *flags;
>
>/* Set the sendkey. */
> - *((char *) 0x41a) = 0x1e;
> - *((char *) 0x41c) = keylen + 0x1e;
> + *((volatile char *) 0x41a) = 0x1e;
> + *((volatile char *) 0x41c) = keylen + 0x1e;
>grub_memcpy ((char *) 0x41e, sendkey, 0x20);
>
>/* Transform "any ctrl" to "right ctrl" flag. */
> --
> 2.11.0
Unfortunately the volatile keyword doesn't help on a more recent gcc-12
build [1]. With that -Warray-bounds warning [2] is emitted this time
than -Wstringop-overflow.
I believe this is caused by this gcc regression in which hardwired
literal address is treated as NULL plus an offset, while there's no good
way to tell that literal address being an invalid accesses at non-zero
offsets to null pointers or not:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Before upstream comes up with a solution or introducing new annotation
for literal pointer. For the time being their recommedation is to
suppress the warning with #pragma or use volatile pointer which appears
to not work for gcc-12.
Instead of inserting #pragma all over the places to avoid the diagnose
of Warray-bounds. I think we can try to port absolute_pointer [3] and
RELOC_HIDE [4] used by the linux kernel to disconnect a pointer using
literal address from its original object hence gcc won't make
assumptions on the boundary while doing pointer arithmetic. This sounds
a better way to go as it can work across gcc versions.
I am halfway in preparing the patch to wrap literal pointers in
absolute_pointer. Before posting it here, I'd like to know do we have
any other prefernece like just disabling it via #pragma as that sounds
more like a norm?
Thanks,
Michael
[3]
https://elixir.bootlin.com/linux/v5.16.14/source/include/linux/compiler.h#L180
[4]
https://elixir.bootlin.com/linux/v5.16.14/source/include/linux/compiler-gcc.h#L31
[1]
abuild@local:~> gcc --version
gcc (SUSE Linux) 12.0.1 20220228 (experimental) [revision
37b583b9d7719f663656ce65ac822c11471fb540]
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[2]
[ 195s] ../../grub-core/commands/i386/pc/sendkey.c: In function
'grub_sendkey_postboot':
[ 195s] ../../grub-core/commands/i386/pc/sendkey.c:221:3: error: array
subscript 0 is outside array bounds of 'grub_uint32_t[0]' {aka 'unsigned
int[]'} [-Werror=array-bounds]
[ 195s] 221 | *flags = oldflags;
[ 195s] | ^~
[ 195s] ../../grub-core/commands/i386/pc/sendkey.c:223:3: error: array
subscript 0 is outside array bounds of 'volatile char[0]' [-Werror=array-bounds]
[ 195s] 223 | *((volatile char *) 0x41a) = 0x1e;
[ 195s] | ^~
[ 195s] ../../grub-core/commands/i386/pc/sendkey.c:224:3: error: array
subscript 0 is outside array bounds of 'volatile char[0]' [-Werror=array-bounds]
[ 195s] 224 | *((volatile char *) 0x41c) = 0x1e;
[ 195s] | ^~
[ 195s] ../../grub-core/term/ns8250.c: In function 'grub_ns8250_init':
[ 195s] ../../grub-core/term/ns8250.c:242:26: error: array subscript 0 is
outside array bounds of 'const short unsigned int[0]' [-Werror=array-bounds]
[ 195s] 242 | if (serial_hw_io_addr[i])
[ 195s] | ~^~~
[ 195s] ../../grub-core/term/ns8250.c:262:46: error: array subscript 0 is
outside array bounds of 'const short unsigned int[0]' [-Werror=array-bounds]
[ 195s] 262 | com_ports[i].port = serial_hw_io_addr[i];
[ 195s] | ~^~~
[ 195s] ../../grub-core/term/ns8250.c: In function 'grub_ns8250_hw_get_port':
[ 195s] ../../grub-core/term/ns8250.c:277:29: error: array subscript 0 is
[PATCH v2] Use full btrfs bootloader area
Up to now GRUB can only embed to the first 64 KiB before primary
superblock of btrfs, effectively limiting the size that could
consequently pose restrictions to feature enablement like advanced zstd
compression.
This patch attempts to utilize full unused area reserved by btrfs for
bootloader outlined in the document [1] where this paragraph quoted.
"The first 1MiB on each device is unused with the exception of primary
superblock that is on the offset 64KiB and spans 4KiB."
Apart from that, adjacent sectors to superblock and first block group
are not used for embedding in case of overflow and logged access to
adjacent sectors could be useful to tracing it up.
This patch has been tested to provide out of the box support to btrfs
zstd compression with which GRUB has been installed to the partition.
[1] https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)#BOOTLOADER_SUPPORT
Signed-off-by: Michael Chang
---
grub-core/fs/btrfs.c | 91 +---
include/grub/disk.h | 2 +
2 files changed, 80 insertions(+), 13 deletions(-)
diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
index c908b460f..e58dcf242 100644
--- a/grub-core/fs/btrfs.c
+++ b/grub-core/fs/btrfs.c
@@ -2483,6 +2483,33 @@ grub_btrfs_label (grub_device_t device, char **label)
}
#ifdef GRUB_UTIL
+
+struct embed_region {
+ unsigned int start;
+ unsigned int secs;
+};
+
+/*
+ * https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)#BOOTLOADER_SUPPORT
+ * The first 1MiB on each device is unused with the exception of primary
+ * superblock that is on the offset 64KiB and spans 4KiB.
+ */
+
+static const struct {
+ struct embed_region available;
+ struct embed_region used[6];
+} btrfs_head = {
+ .available = {0, GRUB_DISK_KiB_TO_SECTORS (1024)}, /* The first 1MiB */
+ .used = {
+{0, 1},/* boot.S */
+{GRUB_DISK_KiB_TO_SECTORS (64) - 1, 1},/* overflow
guard */
+{GRUB_DISK_KiB_TO_SECTORS (64), GRUB_DISK_KiB_TO_SECTORS (4)}, /* 4KiB
superblock */
+{GRUB_DISK_KiB_TO_SECTORS (68), 1},/* overflow
guard */
+{GRUB_DISK_KiB_TO_SECTORS (1024) - 1, 1}, /* overflow
guard */
+{0, 0} /* array
terminator */
+ }
+};
+
static grub_err_t
grub_btrfs_embed (grub_device_t device __attribute__ ((unused)),
unsigned int *nsectors,
@@ -2490,25 +2517,63 @@ grub_btrfs_embed (grub_device_t device __attribute__
((unused)),
grub_embed_type_t embed_type,
grub_disk_addr_t **sectors)
{
- unsigned i;
+ unsigned int i, j;
+ const struct embed_region *u;
+ grub_disk_addr_t *map;
+ unsigned int n = 0;
if (embed_type != GRUB_EMBED_PCBIOS)
return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET,
"BtrFS currently supports only PC-BIOS embedding");
- if (64 * 2 - 1 < *nsectors)
-return grub_error (GRUB_ERR_OUT_OF_RANGE,
- N_("your core.img is unusually large. "
- "It won't fit in the embedding area"));
-
- *nsectors = 64 * 2 - 1;
- if (*nsectors > max_nsectors)
-*nsectors = max_nsectors;
- *sectors = grub_calloc (*nsectors, sizeof (**sectors));
- if (!*sectors)
+ map = grub_calloc (btrfs_head.available.secs, sizeof (*map));
+ if (map == NULL)
return grub_errno;
- for (i = 0; i < *nsectors; i++)
-(*sectors)[i] = i + 1;
+
+ /*
+ * Populating the map array so that it can be used to index if a disk
+ * address is available to embed
+ * 0: available
+ * 1: unavailable
+ */
+ for (u = btrfs_head.used; u->secs; ++u)
+{
+ unsigned int end = u->start + u->secs;
+
+ if (end > btrfs_head.available.secs)
+end = btrfs_head.available.secs;
+ for (i = u->start; i < end; ++i)
+map[i] = 1;
+}
+
+ /* Adding up n until it matches total size of available embedding area */
+ for (i = 0; i < btrfs_head.available.secs; ++i)
+if (map[i] == 0)
+ n++;
+
+ if (n < *nsectors)
+{
+ grub_free (map);
+ return grub_error (GRUB_ERR_OUT_OF_RANGE,
+N_("your core.img is unusually large. "
+ "It won't fit in the embedding area"));
+}
+
+ if (n > max_nsectors)
+n = max_nsectors;
+
+ /*
+ * Populating the array so that it can used to index disk block address for
+ * an image file's offset to be embedded on disk. The unit is in sectors.
+ * i: The disk block address relative to btrfs_head.available.start
+ * j: The offset in image file
+ */
+ for (i = 0, j = 0; i < btrfs_head.available.secs && j < n; ++i)
+if (map[i] == 0)
+ map[j++] = btrfs_head.available.start + i;
+
+ *nsectors = n;
+ *sectors = map;
return GRUB_ERR_NONE;
}
diff --git a/include/grub/disk.h b/include/grub/disk.h
index f95aca929..06210a704 100644
--- a/include/grub/disk.h
+++
[PATCH] grub-mkconfig: restore umask for grub.cfg
Since commit:
ab2e53c8a grub-mkconfig: Honor a symlink when generating configuration
by grub-mkconfig
has inadvertently discarded umask for creating grub.cfg in the process
of grub-mkconfig. The resulting wrong permission (0644) would allow
unprivileged users to read grub's configuration file content. This
presents a low confidentiality risk as grub.cfg may contain non-secured
plain-text passwords.
This patch restores the missing umask and set the file mode of creation
to 0600 preventing unprivileged access.
Fixes: CVE-2021-3981
Signed-off-by: Michael Chang
---
util/grub-mkconfig.in | 2 ++
1 file changed, 2 insertions(+)
diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
index c3ea7612e..41af98135 100644
--- a/util/grub-mkconfig.in
+++ b/util/grub-mkconfig.in
@@ -301,7 +301,9 @@ and /etc/grub.d/* files or please file a bug report with
exit 1
else
# none of the children aborted with error, install the new grub.cfg
+oldumask=$(umask); umask 077
cat ${grub_cfg}.new > ${grub_cfg}
+umask $oldumask
rm -f ${grub_cfg}.new
fi
fi
--
2.31.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Use full btrfs bootloader area
On Wed, Dec 01, 2021 at 05:16:56PM +0100, Daniel Kiper wrote:
> On Tue, Nov 02, 2021 at 04:11:06PM +0800, Michael Chang via Grub-devel wrote:
> > Up to now grub can only embed to the first 64 KiB before primary
>
> s/grub/GRUB/
>
> > superblock of btrfs, effectively limiting the size that could
> > consequently pose restrictions to feature enablement like advancing zstd
>
> s/advancing/advanced/?
>
> > compression.
> >
> > This patch attempts to utilize full unused area reserved by btrfs for
> > bootloader outlined in the document [1] where this paragraph quoted.
> >
> > "The first 1MiB on each device is unused with the exception of primary
> > superblock that is on the offset 64KiB and spans 4KiB."
> >
> > Apart from that, adjacent sectors to superblock and first block group
> > are not used for embedding in case of overflow and it's tracing.
>
> What do you mean by "it's tracing" here?
Maybe can put it this way "useful in tracing the problem of overflow by
logging it's access to adjacent sectors and don't overwrite it".
>
> > This patch has been tested to provide out of the box support to btrfs
> > zstd compression with which grub has been installed to the partition.
>
> s/grub/GRUB/
>
> > [1]
> > https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)#BOOTLOADER_SUPPORT
> >
> > Signed-off-by: Michael Chang
> > ---
> > grub-core/fs/btrfs.c | 80 +---
> > 1 file changed, 67 insertions(+), 13 deletions(-)
> >
> > diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
> > index 63203034d..dcd4635f1 100644
> > --- a/grub-core/fs/btrfs.c
> > +++ b/grub-core/fs/btrfs.c
> > @@ -2159,6 +2159,35 @@ grub_btrfs_label (grub_device_t device, char **label)
> > }
> >
> > #ifdef GRUB_UTIL
> > +
> > +struct embed_region {
> > + unsigned int offset;
>
> s/offset/start/
>
> > + unsigned int len;
>
> s/len/secs/
>
> > +};
> > +
> > +#define KB_TO_SECTOR(x) ((x) << 1)
>
> I think this macro belongs to the include/grub/disk.h. Additionally, it
> should be named, e.g., KiB_TO_GRUB_DISK_SECS and use GRUB_DISK_SECTOR_BITS.
>
> > +/*
> > + *
> > https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)#BOOTLOADER_SUPPORT
> > + * The first 1MiB on each device is unused with the exception of primary
> > + * superblock that is on the offset 64KiB and spans 4KiB.
> > + */
> > +
> > +static const struct {
> > + struct embed_region available;
> > + struct embed_region used[6];
> > +} area = {
>
> s/area/btrfs_head/?
>
> > + .available = {0, KB_TO_SECTOR(1024)}, /* The first 1MiB */
>
> Missing space between KB_TO_SECTOR and "(".
>
> > + .used = {
> > +{0, 1}, /* boot.S */
> > +{KB_TO_SECTOR(64) - 1, 1}, /* overflow guard */
>
> Ditto and below...
>
> > +{KB_TO_SECTOR(64), KB_TO_SECTOR(4)}, /* 4KiB superblock */
> > +{KB_TO_SECTOR(68), 1}, /* overflow guard */
> > +{KB_TO_SECTOR(1024) - 1, 1}, /* overflow guard */
> > +{0, 0} /* array terminator */
> > + }
> > +};
> > +
> > static grub_err_t
> > grub_btrfs_embed (grub_device_t device __attribute__ ((unused)),
> > unsigned int *nsectors,
> > @@ -2166,25 +2195,50 @@ grub_btrfs_embed (grub_device_t device
> > __attribute__ ((unused)),
> > grub_embed_type_t embed_type,
> > grub_disk_addr_t **sectors)
> > {
> > - unsigned i;
> > + unsigned int i, j;
> > + const struct embed_region *u;
> > + grub_disk_addr_t *map;
> > + unsigned int n = 0;
> >
> >if (embed_type != GRUB_EMBED_PCBIOS)
> > return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET,
> >"BtrFS currently supports only PC-BIOS embedding");
> >
> > - if (64 * 2 - 1 < *nsectors)
> > -return grub_error (GRUB_ERR_OUT_OF_RANGE,
> > - N_("your core.img is unusually large. "
> > - "It won't fit in the embedding area"));
> > -
> > - *nsectors = 64 * 2 - 1;
> > - if (*nsectors > max_nsectors)
> > -*nsectors = max_nsectors;
> > - *sectors = grub_calloc (*nsectors, sizeof (**sectors));
> > - if (!*sectors)
> > + map = grub_calloc (area.available.len, sizeof (*map));
> > + if (!map)
>
Re: [PATCH 2/2] ieee1275: set real-base in the PowerPC IEEE1275 Note to 32MB
On Tue, Nov 16, 2021 at 02:42:05PM +1100, Daniel Axtens wrote: > Background > -- > > Figuring out how to lay out memory in powerpc OpenFirmware is a bit > of a complicate dance. > > Firstly, firmware needs to reserve a little bit of space for things > like interrupt vectors that live at a fixed address. This is usually > 0x4000 bytes. PFW calls this "stage 1" (of the firmware, not the > bootloader!) > > As discussed in the previous patch, the ELF image is loaded at > 'load-base' before it's unpacked. load-base is, by default, set at the > end of stage 1. From there, the ELF loader unpacks the binary to > wherever the program headers say and the program is executed. > > Next in memory, we need space for the rest of firmware. (PFW calls > this "stage 2" of firmware.) The starting address begins at > 'real-base'.* We need to not run past real-base when loading our ELF > binary. > > load-base and real-base have defaults from firmware, and may be > configurable in various ways. > > On PFW: > > - real-base defaults to 12MB (0xc0) > > - real-base is configurable with the IEEE1275 ELF note. > > - a proprietary OS bootloader configures real-base to >0x200 (32MB). > > On SLOF: > > - real-base is set dynamically towards the end of accessible memory. > > - real-base is not configurable. > > On 32-bit, I'm not sure quite what the story is. I don't have any > 32-bit Apple hardware to test with. However, with this change, grub > still loads and runs, including when I hack up the tests to install > the note by default. > > * I'm assuming here that the firmware doesn't do virtual mode. This is > true on Power for both PFW and SLOF; Apple OF implementations may do > things differently. > > Moving real-base > > > To account for growing grub binary sizes, we want to try to expand the > amount of memory that we have to work with. We have the following > constraints and inputs: > > - A good practical limit for the size of the grub binary is 8MB, as >that's about the size of the PReP partition on a number of distro >setups. (See previous patch.) > > - We also want things to work if people forget to include the >note. Even if distros build it in to signed images, people >running grub-install will probably forget to set it and we don't >want to break their systems. (Helpfully, if you're running >grub-install manually there's a decent chance you're not building >in a bunch of modules so things are likely to be smaller anyway.) > > - We want to avoid doing anything too novel with enterprise software. > > So when the note is included, set real-base to 32MB. > > Results > --- > > This means that: > > - The ELF file will be loaded at 0x4000 and have just short of 8MB to >fit into. (This is entirely the work of the previous patch - the >8MB limitation is because we now load at 8MB instead of 2MB.) > > - Nothing changes on SLOF, because SLOF ignores the note. We have >oodles of space in SLOF. > > - On PFW when the note is not installed, we have about 4MB of space >for ELF loader to put the program into (the gap between 8MB and the >default real-base of 12MB). This is well more than any current grub >image uses. > > - On PFW when the note _is_ installed, we will have about 24MB of >space to put the program bits into. This is well more than we're >likely to use unless people start putting very large arrays in BSS, >but it means we're aligned with a proprietary bootloader and >therefore we can be assured that some testing has been done. May I ask why 'proprietary' is used here to describe the usecase ? Does it possess any meaningful words like supportability to the firmware vendor that OS vendor have to think over before enabling the note for a 'general' feature like powerpc secure boot ? Thanks, Michael > > Signed-off-by: Daniel Axtens > --- > util/grub-mkimagexx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/util/grub-mkimagexx.c b/util/grub-mkimagexx.c > index d78fa3e53308..2ac40b82a22d 100644 > --- a/util/grub-mkimagexx.c > +++ b/util/grub-mkimagexx.c > @@ -467,7 +467,7 @@ SUFFIX (grub_mkimage_generate_elf) (const struct > grub_install_image_target_desc >note_ptr->header.n_type = grub_host_to_target32 > (GRUB_IEEE1275_NOTE_TYPE); >strcpy (note_ptr->name, GRUB_IEEE1275_NOTE_NAME); >note_ptr->descriptor.real_mode = grub_host_to_target32 (0x); > - note_ptr->descriptor.real_base = grub_host_to_target32 (0x00c0); > + note_ptr->descriptor.real_base = grub_host_to_target32 (0x0200); >note_ptr->descriptor.real_size = grub_host_to_target32 (0x); >note_ptr->descriptor.virt_base = grub_host_to_target32 (0x); >note_ptr->descriptor.virt_size = grub_host_to_target32 (0x); > -- > 2.32.0 > > > ___ > Grub-devel mailing list > Grub
Re: [PATCH 0/2] ieee1275/powerpc: implement ofpath to enable hint feature for FC and dm devices
On Tue, Nov 16, 2021 at 08:29:49AM +0100, Javier Martinez Canillas wrote: > Hello Diego, > > On 11/20/20 19:43, Diego Domingos wrote: > > The grub-ofpathname and hint feature for ieee1275 are not working since > > there is no code implemented to get the information needed about fibre > > channel devices and device mapper. > > > > This patch series implements the codes for both groups of devices and with > > them we can get the --hint-ieee1275 working properly. > > > > We are using these patches in Fedora and RHEL for some time and > it does solve the mentioned issues. > > Tested-by: Javier Martinez Canillas Same with SUSE/openSUSE. Tested-by: Michael Chang Thanks, Michael > > Best regards, > -- > Javier Martinez Canillas > Linux Engineering > Red Hat > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Use full btrfs bootloader area
Up to now grub can only embed to the first 64 KiB before primary
superblock of btrfs, effectively limiting the size that could
consequently pose restrictions to feature enablement like advancing zstd
compression.
This patch attempts to utilize full unused area reserved by btrfs for
bootloader outlined in the document [1] where this paragraph quoted.
"The first 1MiB on each device is unused with the exception of primary
superblock that is on the offset 64KiB and spans 4KiB."
Apart from that, adjacent sectors to superblock and first block group
are not used for embedding in case of overflow and it's tracing.
This patch has been tested to provide out of the box support to btrfs
zstd compression with which grub has been installed to the partition.
[1] https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)#BOOTLOADER_SUPPORT
Signed-off-by: Michael Chang
---
grub-core/fs/btrfs.c | 80 +---
1 file changed, 67 insertions(+), 13 deletions(-)
diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
index 63203034d..dcd4635f1 100644
--- a/grub-core/fs/btrfs.c
+++ b/grub-core/fs/btrfs.c
@@ -2159,6 +2159,35 @@ grub_btrfs_label (grub_device_t device, char **label)
}
#ifdef GRUB_UTIL
+
+struct embed_region {
+ unsigned int offset;
+ unsigned int len;
+};
+
+#define KB_TO_SECTOR(x) ((x) << 1)
+
+/*
+ * https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)#BOOTLOADER_SUPPORT
+ * The first 1MiB on each device is unused with the exception of primary
+ * superblock that is on the offset 64KiB and spans 4KiB.
+ */
+
+static const struct {
+ struct embed_region available;
+ struct embed_region used[6];
+} area = {
+ .available = {0, KB_TO_SECTOR(1024)}, /* The first 1MiB */
+ .used = {
+{0, 1}, /* boot.S */
+{KB_TO_SECTOR(64) - 1, 1}, /* overflow guard */
+{KB_TO_SECTOR(64), KB_TO_SECTOR(4)}, /* 4KiB superblock */
+{KB_TO_SECTOR(68), 1}, /* overflow guard */
+{KB_TO_SECTOR(1024) - 1, 1}, /* overflow guard */
+{0, 0} /* array terminator */
+ }
+};
+
static grub_err_t
grub_btrfs_embed (grub_device_t device __attribute__ ((unused)),
unsigned int *nsectors,
@@ -2166,25 +2195,50 @@ grub_btrfs_embed (grub_device_t device __attribute__
((unused)),
grub_embed_type_t embed_type,
grub_disk_addr_t **sectors)
{
- unsigned i;
+ unsigned int i, j;
+ const struct embed_region *u;
+ grub_disk_addr_t *map;
+ unsigned int n = 0;
if (embed_type != GRUB_EMBED_PCBIOS)
return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET,
"BtrFS currently supports only PC-BIOS embedding");
- if (64 * 2 - 1 < *nsectors)
-return grub_error (GRUB_ERR_OUT_OF_RANGE,
- N_("your core.img is unusually large. "
- "It won't fit in the embedding area"));
-
- *nsectors = 64 * 2 - 1;
- if (*nsectors > max_nsectors)
-*nsectors = max_nsectors;
- *sectors = grub_calloc (*nsectors, sizeof (**sectors));
- if (!*sectors)
+ map = grub_calloc (area.available.len, sizeof (*map));
+ if (!map)
return grub_errno;
- for (i = 0; i < *nsectors; i++)
-(*sectors)[i] = i + 1;
+
+ for (u = area.used; u->len; ++u)
+{
+ unsigned int end = u->offset + u->len;
+
+ if (end > area.available.len)
+end = area.available.len;
+ for (i = u->offset; i < end; ++i)
+map[i] = 1;
+}
+
+ for (i = 0; i < area.available.len; ++i)
+if (map[i] == 0)
+ n++;
+
+ if (n < *nsectors)
+{
+ grub_free (map);
+ return grub_error (GRUB_ERR_OUT_OF_RANGE,
+N_("your core.img is unusually large. "
+ "It won't fit in the embedding area"));
+}
+
+ if (n > max_nsectors)
+n = max_nsectors;
+
+ for (i = 0, j = 0; i < area.available.len && j < n; ++i)
+if (map[i] == 0)
+ map[j++] = area.available.offset + i;
+
+ *nsectors = n;
+ *sectors = map;
return GRUB_ERR_NONE;
}
--
2.31.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] fs/btrfs: Make extent item iteration to handle gaps
On Thu, Oct 28, 2021 at 03:36:10PM +0800, The development of GNU GRUB wrote:
> Gentle ping?
>
> Without this patch, the new mkfs.btrfs NO_HOLES feature would break any
> kernel/initramfs with hole in it.
>
> And considering the modification is already small, I believe this patch is
> definitely worthy as a bug fix.
+1
This does worth more attention as booting would have been blocked.
>
> Thanks,
> Qu
>
> On 2021/10/16 09:40, Qu Wenruo wrote:
> > [BUG]
> > Grub btrfs implementation can't handle two very basic btrfs file
> > layouts:
> >
> > 1. Mixed inline/regualr extents
> > # mkfs.btrfs -f test.img
> > # mount test.img /mnt/btrfs
> > # xfs_io -f -c "pwrite 0 1k" -c "sync" -c "falloc 0 4k" \
> >-c "pwrite 4k 4k" /mnt/btrfs/file
> > # umount /mnt/btrfs
> > # ./grub-fstest ./grub-fstest --debug=btrfs ~/test.img hex "/file"
> >
> > Such mixed inline/regular extents case is not recommended layout,
> > but all existing tools and kernel can handle it without problem
> >
> > 2. NO_HOLES feature
> > # mkfs.btrfs -f test.img -O no_holes
> > # mount test.img /mnt/btrfs
> > # xfs_io -f -c "pwrite 0 4k" -c "pwrite 8k 4k" /mnt/btrfs/file
> > # umount /mnt/btrfs
> > # ./grub-fstest ./grub-fstest --debug=btrfs ~/test.img hex "/file"
> >
> > NO_HOLES feature is going to be the default mkfs feature in the incoming
> > v5.15 release, and kernel has support for it since v4.0.
> >
> > [CAUSE]
> > The way GRUB btrfs code iterates through file extents relies on no gap
> > between extents.
> >
> > If any gap is hit, then grub btrfs will error out, without any proper
> > reason to help debug the bug.
> >
> > This is a bad assumption, since a long long time ago btrfs has a new
> > feature called NO_HOLES to allow btrfs to skip the padding hole extent
> > to reduce metadata usage.
> >
> > The NO_HOLES feature is already stable since kernel v4.0 and is going to
> > be the default mkfs feature in the incoming v5.15 btrfs-progs release.
> >
> > [FIX]
> > When there is a extent gap, instead of error out, just try next item.
> >
> > This is still not ideal, as kernel/progs/U-boot all do the iteration
> > item by item, not relying on the file offset continuity.
> >
> > But it will be way more time consuming to correct the whole behavior
> > than starting from scratch to build a proper designed btrfs module for GRUB.
> >
> > Signed-off-by: Qu Wenruo
> > ---
> > grub-core/fs/btrfs.c | 33 ++---
> > 1 file changed, 30 insertions(+), 3 deletions(-)
> >
> > diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
> > index 63203034dfc6..4fbcbec7524a 100644
> > --- a/grub-core/fs/btrfs.c
> > +++ b/grub-core/fs/btrfs.c
> > @@ -1443,6 +1443,7 @@ grub_btrfs_extent_read (struct grub_btrfs_data *data,
> > grub_size_t csize;
> > grub_err_t err;
> > grub_off_t extoff;
> > + struct grub_btrfs_leaf_descriptor desc;
> > if (!data->extent || data->extstart > pos || data->extino != ino
> > || data->exttree != tree || data->extend <= pos)
> > {
> > @@ -1455,7 +1456,7 @@ grub_btrfs_extent_read (struct grub_btrfs_data *data,
> > key_in.type = GRUB_BTRFS_ITEM_TYPE_EXTENT_ITEM;
> > key_in.offset = grub_cpu_to_le64 (pos);
> > err = lower_bound (data, &key_in, &key_out, tree,
> > -&elemaddr, &elemsize, NULL, 0);
> > +&elemaddr, &elemsize, &desc, 0);
> > if (err)
> > return -1;
> > if (key_out.object_id != ino
> > @@ -1494,10 +1495,36 @@ grub_btrfs_extent_read (struct grub_btrfs_data
> > *data,
> > PRIxGRUB_UINT64_T "\n",
> > grub_le_to_cpu64 (key_out.offset),
> > grub_le_to_cpu64 (data->extent->size));
> > + /*
> > + * The way of extent item iteration is pretty bad, it completely
> > + * requires all extents are contiguous, which is not ensured.
> > + *
> > + * Features like NO_HOLE and mixed inline/regular extents can cause
> > + * gaps between file extent items.
> > + *
> > + * The correct way is to follow kernel/U-boot to iterate item by
> > + * item, without any assumption on the file offset continuity.
> > + *
> > + * Here we just manually skip to next item and re-do the verification.
> > + *
> > + * TODO: Rework the whole extent item iteration code, if not the
> > + * whole btrfs implementation.
> > + */
> > if (data->extend <= pos)
> > {
> > - grub_error (GRUB_ERR_BAD_FS, "extent not found");
> > - return -1;
> > + err = next(data, &desc, &elemaddr, &elemsize, &key_out);
> > + if (err < 0)
> > + return -1;
> > + /* No next item for the inode, we hit the end */
> > + if (err == 0 || key_out.object_id != ino ||
> > + key_out.type != GRUB_BTRFS_ITEM_TYPE_EXTENT_ITEM)
> > + return
Re: [PATCH] i386-pc: build btrfs zstd support into separate module
On Tue, Oct 26, 2021 at 02:55:21PM +0200, Daniel Kiper wrote: > On Fri, Sep 10, 2021 at 05:22:22PM +0800, Michael Chang via Grub-devel wrote: > > On Wed, Sep 08, 2021 at 09:37:52PM +0200, Daniel Kiper wrote: > > > On Fri, Sep 03, 2021 at 09:21:39AM +0800, Michael Chang via Grub-devel > > > wrote: > > > > On Thu, Sep 02, 2021 at 02:12:52PM +0200, Daniel Kiper wrote: > > > > > On Thu, Sep 02, 2021 at 01:48:30PM +0800, Michael Chang via > > > > > Grub-devel wrote: > > > > > > On Wed, Sep 01, 2021 at 06:38:22PM +0200, Daniel Kiper wrote: > > > > > > > On Tue, Aug 31, 2021 at 03:12:28PM +0800, Michael Chang via > > > > > > > Grub-devel wrote: > > > > [snip] > > > > > > just that I can't resist to fix problem from our users who opted to use > > > > "btrfs partition" which differs to "short mbr gap" with a lot more user > > > > base and sensible usecases. > > > > > > > > FWIW we want to address this problem, because mbr gap is adjustable via > > > > re-partitioning but btrfs bootloader area is not. > > > > > > Huh! The "btrfs partition" sounds like not resizable MBR gap! I am not > > > happy with it just at the beginning. Anyway, could you explain your use > > > case in more details including example commands and why core.img seems > > > landing in the "btrfs partition". I am especially curious about the > > > latter because I think the "btrfs partition" and things like that was > > > designed for something else, e.g., storing grubenv data. And why this > > > solution is i386 specific? > > > > Installing to btrfs partition is not something exotic to grub, it is > > actually a supported usecase by grub for a long time. Also zfs has > > similar design, see: > > > > c7ba4f698 Support BtrFS embedding. > > ba102053c Support ZFS embedding. > > > > To make it happen, you just have to point the btrfs device to > > grub-install and it will setup and embed image there. That worked quite > > nicely until the zstd support came into play. > > > > On current git head, the command fails with core.img is too large. > > > > # ./grub-install -d ./grub-core /dev/vda2 > > Installing for i386-pc platform. > > ./grub-install: warning: your core.img is unusually large. It won't fit > > in the embedding area. > > ./grub-install: error: filesystem `btrfs' doesn't support blocklists. > > > > With this patch, the embedding still works but warns the user zstd is > > disabled, also instructing them to use MBR if they need the zstd feature > > to work. > > > > # ./grub-install -d ./grub-core /dev/vda2 > > Installing for i386-pc platform. > > ./grub-install: warning: btrfs zstd compression is disabled, please change > > install device to disk. > > Installation finished. No error reported. > > > > It is very i386-pc centric, as it is often used by legacy mbr boot code > > with which active partition is chainloaded. Some people still thinks > > this is the right thing to do and feels more comfortable this way to > > manage their multiple distrubution booting, compared with os-prober. > > I do not like this solution because it is similar to all the patches > trying to solve small MBR problem. Though, after chatting with Btrfs > folks in Oracle, it seems to me there is better solution for this issue. > I think we should make the GRUB installer smarter. If it cannot put the > core image in first 64 KiB before primary superblock it should install > the core image behind the primary superblock, i.e. starting from > 64 KiB + 4 KiB but below 1 MiB. Please take a look at [1] which nicely > explains the Btrfs bootloader support. Does it make sense for you? Yes. The idea is brilliant and would be the sanest solution out there. I'll try to come up with a patch and discuss here. > > Daniel > > [1] > https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)#BOOTLOADER_SUPPORT Thanks for pointing this out. I am looking for it for a long time as I used to come across this paragraph but not being able to make it again. Thanks, Michael > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Filter out POSIX locale for translation
The POSIX locale is default or native operating system's locale
identical to the C locale, so no translation to human speaking languages
provided.
For this reason we should filter out LANG=POSIX as well as LANG=C upon
generating grub.cfg to avoid looking up for it's gettext's message
catalogs that will consequently result in the unpleasant message.
error: file `/boot/grub/locale/POSIX.gmo' not found
Signed-off-by: Michael Chang
---
util/grub.d/00_header.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/util/grub.d/00_header.in b/util/grub.d/00_header.in
index 93a90233e..f74c2a4c6 100644
--- a/util/grub.d/00_header.in
+++ b/util/grub.d/00_header.in
@@ -191,7 +191,7 @@ EOF
EOF
# Gettext variables and module
-if [ "x${LANG}" != "xC" ] && [ "x${LANG}" != "x" ]; then
+if [ "x${LANG}" != "xC" ] && [ "x${LANG}" != "xPOSIX" ] && [ "x${LANG}" != "x"
]; then
cat << EOF
set locale_dir=\$prefix/locale
set lang=${grub_lang}
--
2.31.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v3] Fix build error in binutils 2.36
The following procedure to build xen/pvgrub is broken.
git clone https://git.savannah.gnu.org/git/grub.git
cd grub
./bootstrap
mkdir build-xen
cd build-xen
../configure --with-platform=xen
make
It fails with the message:
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
section .note.gnu.property VMA [00400158,00400187]
overlaps section .bss VMA [f000,0041e1af]
The most significant factor is that new assembler (gnu as) generates the
.note.gnu.property section as default. This note section overlaps with
.bss because it doesn't reposition with -Wl,-Ttext,0 with which the base
address of .text section is set, rather the address of
.note.gnu.property is calculated for some reason from 0x40 where the
elf executable defaults to start.
Using -Ttext-segment doesn't help either, though it is said to set the
address of the first byte of the text segment according to "man ld".
What it actually does is to override the default 0x40, aka the image
base address, to something else. The entire process can be observed in
the default linker script used by gcc [1]. Therefore we can't expect it
to achieve the same thing as -Ttext given that the first segment where
.text resides is offset by SIZEOF_HEADERS plus some sections may be
preceding it within the first segment. The end result is .text always
has to start with non-zero address with -Wl,-Ttext-segment,0 if using
default linker script.
It is also worth mentioning that binutils upstream apparently doesn't
seem to consider this as a bug [2] and proposed to use
-Wl,-Ttext-segment,0 which's not fruitful as what has been tested by
gentoo [3].
As long as grub didn't use ISA information encoded in
.note.gnu.property, we can safely drop it via -Wa,-mx86-used-note=no
assembler option to fix the linker error above.
This is considered a better approach than using custom linker script to
drop the .note.gnu.property section because object file manipulation can
also be hampered one way or the other in that linker script may not be
helpful. See also this commit removing the section in the process of
objcopy.
6643507ce build: Fix GRUB i386-pc build with Ubuntu gcc
[1] In /usr/lib64/ldscripts/elf_x86_64.x or use 'gcc -Wl,--verbose ...'
PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x40));
. = SEGMENT_START("text-segment", 0x40) + SIZEOF_HEADERS;
[2] Ref: https://sourceware.org/bugzilla/show_bug.cgi?id=27377
[3] Ref: https://bugs.gentoo.org/787221
Signed-off-by: Michael Chang
---
configure.ac | 14 ++
1 file changed, 14 insertions(+)
diff --git a/configure.ac b/configure.ac
index eeb5d2211..8d1c81a73 100644
--- a/configure.ac
+++ b/configure.ac
@@ -840,6 +840,20 @@ if ( test "x$target_cpu" = xi386 || test "x$target_cpu" =
xx86_64 ) && test "x$p
TARGET_CFLAGS="$TARGET_CFLAGS -mno-mmx -mno-sse -mno-sse2 -mno-sse3
-mno-3dnow"
fi
+if ( test "x$target_cpu" = xi386 || test "x$target_cpu" = xx86_64 ); then
+ AC_CACHE_CHECK([whether -Wa,-mx86-used-note works],
[grub_cv_cc_mx86_used_note], [
+CFLAGS="$TARGET_CFLAGS -Wa,-mx86-used-note=no -Werror"
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],
+ [grub_cv_cc_mx86_used_note=yes],
+ [grub_cv_cc_mx86_used_note=no])
+ ])
+
+ if test "x$grub_cv_cc_mx86_used_note" = xyes; then
+TARGET_CFLAGS="$TARGET_CFLAGS -Wa,-mx86-used-note=no"
+TARGET_CCASFLAGS="$TARGET_CCASFLAGS -Wa,-mx86-used-note=no"
+ fi
+fi
+
# GRUB doesn't use float or doubles at all. Yet some toolchains may decide
# that floats are a good fit to run instead of what's written in the code.
# Given that floating point unit is disabled (if present to begin with)
--
2.31.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] Fix build error in binutils 2.36
On Mon, Sep 27, 2021 at 10:18:49AM -0400, Mike Gilbert wrote: > On Mon, Sep 27, 2021 at 5:41 AM Michael Chang via Grub-devel > wrote: > > It is also worth mentioning that binutils upstream apparently doesn't > > seem to consider this as a bug [2] and proposed to use > > -Wl,-Ttext-segment,0 which's not fruitful as what has been tested by > > gentoo [3]. > > ... > > [2] Ref: https://bugs.gentoo.org/787221 > > [3] Ref: https://sourceware.org/bugzilla/show_bug.cgi?id=27377 > > I think these references are reversed. Thanks for spotting this. I will send a new version for correcting this. Regards, Michael ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2] Fix build error in binutils 2.36
The following procedure to build xen/pvgrub is broken.
git clone https://git.savannah.gnu.org/git/grub.git
cd grub
./bootstrap
mkdir build-xen
cd build-xen
../configure --with-platform=xen
make
It fails with the message:
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
section .note.gnu.property VMA [00400158,00400187]
overlaps section .bss VMA [f000,0041e1af]
The most significant factor is that new assembler (gnu as) generates the
.note.gnu.property section as default. This note section overlaps with
.bss because it doesn't reposition with -Wl,-Ttext,0 with which the base
address of .text section is set, rather the address of
.note.gnu.property is calculated for some reason from 0x40 where the
elf executable defaults to start.
Using -Ttext-segment doesn't help either, though it is said to set the
address of the first byte of the text segment according to "man ld".
What it actually does is to override the default 0x40, aka the image
base address, to something else. The entire process can be observed in
the default linker script used by gcc [1]. Therefore we can't expect it
to achieve the same thing as -Ttext given that the first segment where
.text resides is offset by SIZEOF_HEADERS plus some sections may be
preceding it within the first segment. The end result is .text always
has to start with non-zero address with -Wl,-Ttext-segment,0 if using
default linker script.
It is also worth mentioning that binutils upstream apparently doesn't
seem to consider this as a bug [2] and proposed to use
-Wl,-Ttext-segment,0 which's not fruitful as what has been tested by
gentoo [3].
As long as grub didn't use ISA information encoded in
.note.gnu.property, we can safely drop it via -Wa,-mx86-used-note=no
assembler option to fix the linker error above.
This is considered a better approach than using custom linker script to
drop the .note.gnu.property section because object file manipulation can
also be hampered one way or the other in that linker script may not be
helpful. See also this commit removing the section in the process of
objcopy.
6643507ce build: Fix GRUB i386-pc build with Ubuntu gcc
[1] In /usr/lib64/ldscripts/elf_x86_64.x or use 'gcc -Wl,--verbose ...'
PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x40));
. = SEGMENT_START("text-segment", 0x40) + SIZEOF_HEADERS;
[2] Ref: https://bugs.gentoo.org/787221
[3] Ref: https://sourceware.org/bugzilla/show_bug.cgi?id=27377
Signed-off-by: Michael Chang
---
configure.ac | 14 ++
1 file changed, 14 insertions(+)
diff --git a/configure.ac b/configure.ac
index eeb5d2211..8d1c81a73 100644
--- a/configure.ac
+++ b/configure.ac
@@ -840,6 +840,20 @@ if ( test "x$target_cpu" = xi386 || test "x$target_cpu" =
xx86_64 ) && test "x$p
TARGET_CFLAGS="$TARGET_CFLAGS -mno-mmx -mno-sse -mno-sse2 -mno-sse3
-mno-3dnow"
fi
+if ( test "x$target_cpu" = xi386 || test "x$target_cpu" = xx86_64 ); then
+ AC_CACHE_CHECK([whether -Wa,-mx86-used-note works],
[grub_cv_cc_mx86_used_note], [
+CFLAGS="$TARGET_CFLAGS -Wa,-mx86-used-note=no -Werror"
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],
+ [grub_cv_cc_mx86_used_note=yes],
+ [grub_cv_cc_mx86_used_note=no])
+ ])
+
+ if test "x$grub_cv_cc_mx86_used_note" = xyes; then
+TARGET_CFLAGS="$TARGET_CFLAGS -Wa,-mx86-used-note=no"
+TARGET_CCASFLAGS="$TARGET_CCASFLAGS -Wa,-mx86-used-note=no"
+ fi
+fi
+
# GRUB doesn't use float or doubles at all. Yet some toolchains may decide
# that floats are a good fit to run instead of what's written in the code.
# Given that floating point unit is disabled (if present to begin with)
--
2.31.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v3] diskfilter: use nodes in logical volume's segment as member device
Currently the grub_diskfilter_memberlist function returns all physical
volumes added to a volume group to which a logical volume (LV) belongs.
However this is suboptimal as it doesn't fit the intended behavior of
returning underlying devices that make up the LV. To give a clear
picture, the result should be identical to running commands below to
display the logical volumes with underlying physical volumes in use.
localhost:~ # lvs -o lv_name,vg_name,devices /dev/system/root
LV VG Devices
root system /dev/vda2(512)
localhost:~ # lvdisplay --maps /dev/system/root
--- Logical volume ---
...
--- Segments ---
Logical extents 0 to 4604:
Typelinear
Physical volume /dev/vda2
Physical extents512 to 5116
As shown above, we can know system-root lv uses only /dev/vda2 to
allocate it's extents, or we can say that /dev/vda2 is the member device
comprising the system-root lv.
It is important to be precise on the member devices, because that helps
to avoid pulling in excessive dependency. Let's use an example to
demonstrate why it is needed.
localhost:~ # findmnt /
TARGET SOURCE FSTYPE OPTIONS
/ /dev/mapper/system-root ext4 rw,relatime
localhost:~ # pvs
PV VG Fmt Attr PSizePFree
/dev/mapper/data system lvm2 a-- 1020.00m0
/dev/vda2system lvm2 a--19.99g0
localhost:~ # cryptsetup status /dev/mapper/data
/dev/mapper/data is active and is in use.
type:LUKS1
cipher: aes-xts-plain64
keysize: 512 bits
key location: dm-crypt
device: /dev/vdb
sector size: 512
offset: 4096 sectors
size:2093056 sectors
mode:read/write
localhost:~ # vgs
VG #PV #LV #SN Attr VSize VFree
system 2 3 0 wz--n- 20.98g0
localhost:~ # lvs -o lv_name,vg_name,devices
LV VG Devices
data system /dev/mapper/data(0)
root system /dev/vda2(512)
swap system /dev/vda2(0)
We can learn from above that /dev/mapper/data is an encrypted volume and
also gets assigned to volume group 'system' as one of it's physical
volumes. And also it is not used by root device,
/dev/mapper/system-root, for allocating extents, so it shouldn't be
taking part in the process of setting up grub to access root device.
However running grub-install reports error as volume group 'system'
contains encrypted volume.
error: attempt to install to encrypted disk without cryptodisk
enabled. Set `GRUB_ENABLE_CRYPTODISK=y' in file `/etc/default/grub'.
Certainly we can enable GRUB_ENABLE_CRYPTODISK=y and move on, but that
is not always acceptable since the server may need to be booted
unattended. Additionally, typing passphase for every system startup can
be a big hassle of which most users would like to avoid.
This patch solves the problem by returning exact physical volume,
/dev/vda2, rightly used by system-root from the example above, thus
grub-install will not error out because the excessive encrypted device
to boot the root device is not configured.
Signed-off-by: Michael Chang
Tested-by: Olav Reinert
---
grub-core/disk/diskfilter.c | 61 ++---
1 file changed, 44 insertions(+), 17 deletions(-)
diff --git a/grub-core/disk/diskfilter.c b/grub-core/disk/diskfilter.c
index 032011566..1eafc2dc3 100644
--- a/grub-core/disk/diskfilter.c
+++ b/grub-core/disk/diskfilter.c
@@ -300,6 +300,8 @@ grub_diskfilter_memberlist (grub_disk_t disk)
grub_disk_dev_t p;
struct grub_diskfilter_vg *vg;
struct grub_diskfilter_lv *lv2 = NULL;
+ struct grub_diskfilter_segment *seg;
+ unsigned int i, j;
if (!lv->vg->pvs)
return NULL;
@@ -331,27 +333,52 @@ grub_diskfilter_memberlist (grub_disk_t disk)
}
}
- for (pv = lv->vg->pvs; pv; pv = pv->next)
-{
- if (!pv->disk)
+ for (i = 0, seg = lv->segments; i < lv->segment_count; i++, seg++)
+for (j = 0; j < seg->node_count; ++j)
+ if (seg->nodes[j].pv != NULL)
{
- /* TRANSLATORS: This message kicks in during the detection of
-which modules needs to be included in core image. This happens
-in the case of degraded RAID and means that autodetection may
-fail to include some of modules. It's an installation time
-message, not runtime message. */
- grub_util_warn (_("Couldn't find physical volume `%s'."
- " Some modules may be missing from core image."),
- pv->name);
- continue;
+ pv = seg->nodes[j].pv;
+
+ if (!pv->disk)
+ {
+ /*
+ * TRANSLATORS: This message kicks in during the detection of
+ * which modules needs to be included in core image. This happens
+ * in the case of degraded RAID and means that autodetection may
+ * fail to include some of modules. It's an installation time
+
Re: [PATCH] Fix build error in binutils 2.36
On Thu, Sep 16, 2021 at 11:47:57PM +0200, Daniel Kiper wrote: > On Mon, Aug 09, 2021 at 12:37:59PM +0800, Michael Chang via Grub-devel wrote: > > On Thu, Aug 05, 2021 at 03:07:21PM +0200, Daniel Kiper wrote: > > > On Mon, Aug 02, 2021 at 05:41:15PM +0800, Michael Chang via Grub-devel > > > wrote: > > > > The xen build fails on binutils 2.36 with the following error. > > > > > > > > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld: > > > > section .note.gnu.property VMA [00400158,00400187] > > > > overlaps section .bss VMA [f000,0041e1af] > > > > > > Could you send us full command which is failing? > > > > It is reproducible on xen platfrom with all defaults. > > > > git clone https://git.savannah.gnu.org/git/grub.git > > cd grub > > ./bootstrap > > mkdir build-xen > > cd build-xen > > ../configure --with-platform=xen > > make > > > > > Anyway, I would consider writing our own linker script which is dropping > > > .note.gnu.property if we do not need it. > > > > Dropping it from the assembler output is a cleaner cleanup than linker > > script IMHO. We also faced similar issue in the past to stripping off > > this section from soruces of objcopy to produce correct binary. > > > > 6643507ce build: Fix GRUB i386-pc build with Ubuntu gcc > > > > To avoid falling into such trap again when manipulating on object files > > we'd better use assmbler option as the fix once and for all. > > May I ask you to expand commit message with the information above? Sure. No problem. > > > > > The most significant factor is that new assembler (gnu as) generates the > > > > > > Could you give us gas version which does that? > > > > # as --version > > GNU assembler (GNU Binutils; openSUSE Tumbleweed) 2.36.1.20210326-4 > > Copyright (C) 2021 Free Software Foundation, Inc. > > This program is free software; you may redistribute it under the terms of > > the GNU General Public License version 3 or later. > > This program has absolutely no warranty. > > This assembler was configured for a target of `x86_64-suse-linux'. > > > > > > .note.gnu.property section as default. This note section overlaps with > > > > .bss because it doesn't reposition with -Wl,-Ttext,0 with which the base > > > > address of .text section is set, rather the address of > > > > .note.gnu.property is calculated for some reason from 0x40 where the > > > > elf executable defaults to start. > > > > > > Is not it linker bug? > > > > The binutils upstream apparently doesn't seem to consider this as a bug ... > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=27377 > > Please add this information and the link to the bug to the commit message too. > Additionally, I think it is worth mentioning Gentoo Linux bug [1] in it. OK. I'll add the suggested information and refernce to next version. > > I treat this patch more as a workaround than real fix. However, after digging > deeper into this issue I think we do not have better choice here... :-( I feel likewise. It is no sliver bullet but can help us back on track and move on. Thanks, Michael > > Daniel > > [1] https://bugs.gentoo.org/787221 > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] diskfilter: use nodes in logical volume's segment as member device
On Wed, Sep 15, 2021 at 06:00:09PM +0200, Daniel Kiper wrote: > On Thu, Sep 09, 2021 at 09:02:29PM +0800, Michael Chang via Grub-devel wrote: > > Currently the grub_diskfilter_memberlist function returns all physical > > volumes added to a volume group to which a logical volume (LV) belongs. > > However this is suboptimal as it doesn't fit the intended behavior of > > returning underlying devices that make up the LV. To give a clear > > picture, the result should be identical to running commands below to > > display the logical volumes with underlying physical volumes in use. > > > > localhost:~ # lvs -o lv_name,vg_name,devices /dev/system/root > > LV VG Devices > > root system /dev/vda2(512) > > > > localhost:~ # lvdisplay --maps /dev/system/root > > --- Logical volume --- > > ... > > --- Segments --- > > Logical extents 0 to 4604: > > Typelinear > > Physical volume /dev/vda2 > > Physical extents512 to 5116 > > > > As shown above, we can know system-root lv uses only /dev/vda2 to > > allocate it's extents, or we can say that /dev/vda2 is the member device > > comprising the system-root lv. > > > > It is important to be precise on the member devices, because that helps > > to avoid pulling in excessive dependency. Let's use an example to > > demonstrate why it is needed. > > > > localhost:~ # findmnt / > > TARGET SOURCE FSTYPE OPTIONS > > / /dev/mapper/system-root ext4 rw,relatime > > > > localhost:~ # pvs > > PV VG Fmt Attr PSizePFree > > /dev/mapper/data system lvm2 a-- 1020.00m0 > > /dev/vda2system lvm2 a--19.99g0 > > > > localhost:~ # cryptsetup status /dev/mapper/data > > /dev/mapper/data is active and is in use. > > type:LUKS1 > > cipher: aes-xts-plain64 > > keysize: 512 bits > > key location: dm-crypt > > device: /dev/vdb > > sector size: 512 > > offset: 4096 sectors > > size:2093056 sectors > > mode:read/write > > > > localhost:~ # vgs > > VG #PV #LV #SN Attr VSize VFree > > system 2 3 0 wz--n- 20.98g0 > > > > localhost:~ # lvs -o lv_name,vg_name,devices > > LV VG Devices > > data system /dev/mapper/data(0) > > root system /dev/vda2(512) > > swap system /dev/vda2(0) > > > > We can learn from above that /dev/mapper/data is an encrypted volume and > > also gets assigned to volume group 'system' as one of it's physical > > volumes. And also it is not used by root device, > > /dev/mapper/system-root, for allocating extents, so it shouldn't be > > taking part in the process of setting up grub to access root device. > > > > However running grub-install reports error as volume group 'system' > > contains encrypted volume. > > > > error: attempt to install to encrypted disk without cryptodisk > > enabled. Set `GRUB_ENABLE_CRYPTODISK=y' in file `/etc/default/grub'. > > > > Certainly we can enable GRUB_ENABLE_CRYPTODISK=y and move on, but that > > is not always acceptable since the server may need to be booted > > unattended. Additionally, typing passphase for every system startup can > > be a big hassle of which most users would like to avoid. > > > > This patch solves the problem by returning exact physical volume, > > /dev/vda2, rightly used by system-root from the example above, thus > > grub-install will not error out because the excessive encrypted device > > to boot the root device is not configured. > > > > Signed-off-by: Michael Chang > > Tested-by: Olav Reinert > > --- > > grub-core/disk/diskfilter.c | 60 ++--- > > 1 file changed, 43 insertions(+), 17 deletions(-) > > > > diff --git a/grub-core/disk/diskfilter.c b/grub-core/disk/diskfilter.c > > index 6eb2349a6..3d02d56ec 100644 > > --- a/grub-core/disk/diskfilter.c > > +++ b/grub-core/disk/diskfilter.c > > @@ -300,6 +300,8 @@ grub_diskfilter_memberlist (grub_disk_t disk) > >grub_disk_dev_t p; > >struct grub_diskfilter_vg *vg; > >struct grub_diskfilter_lv *lv2 = NULL; > > + struct grub_diskfilter_segment *seg; > > + unsigned int i, j; > > > >if (!lv->vg->pvs) > > return NULL; > > @@ -331,27 +333,51 @@ grub_diskfilter_memberlist (grub_disk_t disk) > >
Re: [PATCH] Fix build error in binutils 2.36
On Tue, Sep 14, 2021 at 10:13:36AM -0400, Mike Gilbert wrote: > On Mon, Aug 9, 2021 at 12:37 AM Michael Chang via Grub-devel > wrote: [snip] > Just wondering if there has been any progress on this issue. > > A few people have commented on the related bug [1] for Gentoo Linux > and a couple have confirmed that this patch fixes the build failure. > However, I haven't found anyone able to test if the resulting code > actually works at run time. We (openSUSE) have been using this patch for months and doesn't see any problem thus far. Thanks, Michael > > [1] https://bugs.gentoo.org/787221 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] i386-pc: build btrfs zstd support into separate module
On Wed, Sep 08, 2021 at 09:37:52PM +0200, Daniel Kiper wrote: > On Fri, Sep 03, 2021 at 09:21:39AM +0800, Michael Chang via Grub-devel wrote: > > On Thu, Sep 02, 2021 at 02:12:52PM +0200, Daniel Kiper wrote: > > > On Thu, Sep 02, 2021 at 01:48:30PM +0800, Michael Chang via Grub-devel > > > wrote: > > > > On Wed, Sep 01, 2021 at 06:38:22PM +0200, Daniel Kiper wrote: > > > > > On Tue, Aug 31, 2021 at 03:12:28PM +0800, Michael Chang via > > > > > Grub-devel wrote: [snip] > > just that I can't resist to fix problem from our users who opted to use > > "btrfs partition" which differs to "short mbr gap" with a lot more user > > base and sensible usecases. > > > > FWIW we want to address this problem, because mbr gap is adjustable via > > re-partitioning but btrfs bootloader area is not. > > Huh! The "btrfs partition" sounds like not resizable MBR gap! I am not > happy with it just at the beginning. Anyway, could you explain your use > case in more details including example commands and why core.img seems > landing in the "btrfs partition". I am especially curious about the > latter because I think the "btrfs partition" and things like that was > designed for something else, e.g., storing grubenv data. And why this > solution is i386 specific? Installing to btrfs partition is not something exotic to grub, it is actually a supported usecase by grub for a long time. Also zfs has similar design, see: c7ba4f698 Support BtrFS embedding. ba102053c Support ZFS embedding. To make it happen, you just have to point the btrfs device to grub-install and it will setup and embed image there. That worked quite nicely until the zstd support came into play. On current git head, the command fails with core.img is too large. # ./grub-install -d ./grub-core /dev/vda2 Installing for i386-pc platform. ./grub-install: warning: your core.img is unusually large. It won't fit in the embedding area. ./grub-install: error: filesystem `btrfs' doesn't support blocklists. With this patch, the embedding still works but warns the user zstd is disabled, also instructing them to use MBR if they need the zstd feature to work. # ./grub-install -d ./grub-core /dev/vda2 Installing for i386-pc platform. ./grub-install: warning: btrfs zstd compression is disabled, please change install device to disk. Installation finished. No error reported. It is very i386-pc centric, as it is often used by legacy mbr boot code with which active partition is chainloaded. Some people still thinks this is the right thing to do and feels more comfortable this way to manage their multiple distrubution booting, compared with os-prober. Thanks, Michael > > Daniel > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2] diskfilter: use nodes in logical volume's segment as member device
Currently the grub_diskfilter_memberlist function returns all physical
volumes added to a volume group to which a logical volume (LV) belongs.
However this is suboptimal as it doesn't fit the intended behavior of
returning underlying devices that make up the LV. To give a clear
picture, the result should be identical to running commands below to
display the logical volumes with underlying physical volumes in use.
localhost:~ # lvs -o lv_name,vg_name,devices /dev/system/root
LV VG Devices
root system /dev/vda2(512)
localhost:~ # lvdisplay --maps /dev/system/root
--- Logical volume ---
...
--- Segments ---
Logical extents 0 to 4604:
Typelinear
Physical volume /dev/vda2
Physical extents512 to 5116
As shown above, we can know system-root lv uses only /dev/vda2 to
allocate it's extents, or we can say that /dev/vda2 is the member device
comprising the system-root lv.
It is important to be precise on the member devices, because that helps
to avoid pulling in excessive dependency. Let's use an example to
demonstrate why it is needed.
localhost:~ # findmnt /
TARGET SOURCE FSTYPE OPTIONS
/ /dev/mapper/system-root ext4 rw,relatime
localhost:~ # pvs
PV VG Fmt Attr PSizePFree
/dev/mapper/data system lvm2 a-- 1020.00m0
/dev/vda2system lvm2 a--19.99g0
localhost:~ # cryptsetup status /dev/mapper/data
/dev/mapper/data is active and is in use.
type:LUKS1
cipher: aes-xts-plain64
keysize: 512 bits
key location: dm-crypt
device: /dev/vdb
sector size: 512
offset: 4096 sectors
size:2093056 sectors
mode:read/write
localhost:~ # vgs
VG #PV #LV #SN Attr VSize VFree
system 2 3 0 wz--n- 20.98g0
localhost:~ # lvs -o lv_name,vg_name,devices
LV VG Devices
data system /dev/mapper/data(0)
root system /dev/vda2(512)
swap system /dev/vda2(0)
We can learn from above that /dev/mapper/data is an encrypted volume and
also gets assigned to volume group 'system' as one of it's physical
volumes. And also it is not used by root device,
/dev/mapper/system-root, for allocating extents, so it shouldn't be
taking part in the process of setting up grub to access root device.
However running grub-install reports error as volume group 'system'
contains encrypted volume.
error: attempt to install to encrypted disk without cryptodisk
enabled. Set `GRUB_ENABLE_CRYPTODISK=y' in file `/etc/default/grub'.
Certainly we can enable GRUB_ENABLE_CRYPTODISK=y and move on, but that
is not always acceptable since the server may need to be booted
unattended. Additionally, typing passphase for every system startup can
be a big hassle of which most users would like to avoid.
This patch solves the problem by returning exact physical volume,
/dev/vda2, rightly used by system-root from the example above, thus
grub-install will not error out because the excessive encrypted device
to boot the root device is not configured.
Signed-off-by: Michael Chang
Tested-by: Olav Reinert
---
grub-core/disk/diskfilter.c | 60 ++---
1 file changed, 43 insertions(+), 17 deletions(-)
diff --git a/grub-core/disk/diskfilter.c b/grub-core/disk/diskfilter.c
index 6eb2349a6..3d02d56ec 100644
--- a/grub-core/disk/diskfilter.c
+++ b/grub-core/disk/diskfilter.c
@@ -300,6 +300,8 @@ grub_diskfilter_memberlist (grub_disk_t disk)
grub_disk_dev_t p;
struct grub_diskfilter_vg *vg;
struct grub_diskfilter_lv *lv2 = NULL;
+ struct grub_diskfilter_segment *seg;
+ unsigned int i, j;
if (!lv->vg->pvs)
return NULL;
@@ -331,27 +333,51 @@ grub_diskfilter_memberlist (grub_disk_t disk)
}
}
- for (pv = lv->vg->pvs; pv; pv = pv->next)
-{
- if (!pv->disk)
+ for (i = 0, seg = lv->segments; i < lv->segment_count; i++, seg++)
+for (j = 0; j < seg->node_count; ++j)
+ if (seg->nodes[j].pv != NULL)
{
- /* TRANSLATORS: This message kicks in during the detection of
-which modules needs to be included in core image. This happens
-in the case of degraded RAID and means that autodetection may
-fail to include some of modules. It's an installation time
-message, not runtime message. */
- grub_util_warn (_("Couldn't find physical volume `%s'."
- " Some modules may be missing from core image."),
- pv->name);
- continue;
+ pv = seg->nodes[j].pv;
+
+ if (!pv->disk)
+ {
+ /* TRANSLATORS: This message kicks in during the detection of
+which modules needs to be included in core image. This happens
+in the case of degraded RAID and means that autodetection may
+fail to include some of modules. It's an installation time
+message, no
Re: [PATCH v2] kern/efi: Adding efi-watchdog command
On Thu, Sep 02, 2021 at 06:50:35PM +0200, Erwan Velu wrote:
> This patch got written by Arthur Mesh from Juniper (now at Apple Sec team).
> It was extracted from
> https://lists.gnu.org/archive/html/grub-devel/2015-09/msg00065.html
>
> Since this email, the this patch was :
> - rebased against the current tree
> - added a default timeout value
> - reworked to be controlled via mkimage
> - reworked to simplify the command line
>
> This commit adds a new command efi-watchdog to manage efi watchdogs.
>
> On server platforms, this allows GRUB to reset the host automatically
> if it wasn't able to succeed at booting in a given timeframe.
> This usually covers the following issues :
> - net boot is too slow and never ends
> - the GRUB is unable to find a proper configuration and fails
>
> Using --efi-watchdog-timeout option at mknetdir time allow users
> controlling the default value of the timer.
> This set the watchdog behavior at the early init of GRUB meaning that
> even if grub is not able to load its configuration file,
> the watchdog will be triggered automatically.
>
> Please note that watchdog only covers GRUB itself.
> As per the UEFI specification :
> The watchdog timer is only used during boot services. On successful
> completion of
> EFI_BOOT_SERVICES.ExitBootServices() the watchdog timer is disabled.
>
> This implies this watchdog doesn't cover the the OS loading.
> If you want to cover this phase of the boot,
> an additional hardware watchdog is required (usually set in the BIOS).
>
> On the command line, a single argument is enough to control the watchdog.
> This argument defines the timeout of the watchdog (in seconds).
> - If 0 > argument < 0x, the watchdog is armed with the associate
> timeout.
> - If argument is set to 0, the watchdog is disarmed.
>
> By default GRUB disable the watchdog and so this patch.
> Therefore, this commit have no impact on the default GRUB's behavior.
>
> This patch is used in production for month on a 50K server platform with
> success.
>
> Signed-off-by: Erwan Velu
> Signed-off-by: Arthur Mesh
> ---
> docs/grub.texi | 13 ++
> grub-core/kern/efi/init.c | 85 -
> include/grub/efi/efi.h | 2 +
> include/grub/kernel.h | 3 +-
> include/grub/util/install.h | 8 +++-
> util/grub-install-common.c | 12 +-
> util/grub-mkimage.c | 11 -
> util/mkimage.c | 23 +-
> 8 files changed, 147 insertions(+), 10 deletions(-)
>
> diff --git a/docs/grub.texi b/docs/grub.texi
> index f8b4b3b21a7f..f012e9537306 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -3991,6 +3991,7 @@ you forget a command, you can run the command
> @command{help}
> * distrust::Remove a pubkey from trusted keys
> * drivemap::Map a drive to another
> * echo::Display a line of text
> +* efi-watchdog::Manipulate EFI watchdog
> * eval::Evaluate agruments as GRUB commands
> * export:: Export an environment variable
> * false:: Do nothing, unsuccessfully
> @@ -4442,6 +4443,18 @@ When interpreting backslash escapes, backslash
> followed by any other
> character will print that character.
> @end deffn
>
> +@node efi-watchdog
> +@subsection efi-watchdog
> +
> +@deffn Command efi-watchdog @var{timeout}
> +Control the EFI system's watchdog timer.
> +Only available in EFI targeted GRUB.
> +
> +When the watchdog exceed @var{timeout}, the system is reset.
> +
> +If @var{timeout} is set to 0, the watchdog is disarmed.
> +
> +@end deffn
>
> @node eval
> @subsection eval
> diff --git a/grub-core/kern/efi/init.c b/grub-core/kern/efi/init.c
> index 7facacf09c7b..532e8533426e 100644
> --- a/grub-core/kern/efi/init.c
> +++ b/grub-core/kern/efi/init.c
> @@ -28,6 +28,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #ifdef GRUB_STACK_PROTECTOR
>
> @@ -82,6 +84,82 @@ stack_protector_init (void)
>
> grub_addr_t grub_modbase;
>
> +static grub_command_t cmd_list;
> +
> +
> +static grub_err_t grub_efi_set_watchdog_timer(unsigned long timeout)
> +{
> + /* User defined code, set to BOOT (B007) for GRUB
> + UEFI SPEC 2.6 reports :
> +The numeric code to log on a watchdog timer timeout event.
> +The firmware reserves codes 0x to 0x.
> +Loaders and operating systems may use other timeout codes.
> + */
> + grub_efi_uint64_t code = 0xB007;
> + grub_efi_status_t status = 0;
> +
> + if (timeout >= 0x)
> +return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("efi-watchdog: timeout must
> be lower than 65535"));
> +
> + if (timeout > 0)
> +grub_printf("grub %s: Arming EFI watchdog at %lu seconds\n",
> PACKAGE_VERSION, timeout);
> + else {
> +grub_printf("grub %s: Disarming EFI watchdog\n", PACKAGE_VERSION);
> +code = 0;
> + }
> +
> + status = efi_call_4
Re: [PATCH] i386-pc: build btrfs zstd support into separate module
On Thu, Sep 02, 2021 at 02:12:52PM +0200, Daniel Kiper wrote: > On Thu, Sep 02, 2021 at 01:48:30PM +0800, Michael Chang via Grub-devel wrote: > > On Wed, Sep 01, 2021 at 06:38:22PM +0200, Daniel Kiper wrote: > > > On Tue, Aug 31, 2021 at 03:12:28PM +0800, Michael Chang via Grub-devel > > > wrote: > > > > The zstd support in btrfs brings significant size increment to the > > > > on-disk image that it can no longer fit into btrfs bootloader area and > > > > short mbr gap. > > > > > > > > In order to support grub update on outstanding i386-pc setup with these > > > > size constraints remain in place, here we build the zstd suppprt of > > > > btrfs into a separate module, named btrfs_zstd, to alleviate the size > > > > change. Please note this only makes it's way to i386-pc, other > > > > architecture is not affected. > > > > > > I am OK with extracting zstd code from btrfs code. However, I want that be > > > done for all architectures and platforms. No exceptions. > > > > May I ask for more background about this decision ? > > Yes, I want the same code and behavior for all architectures and > platforms if possible. > > > Given that btrfs compression is per file property and can be > > recompressed on the fly, there is no way to detect it beforehand thus > > the safest bet is to assume that it is always needed. In other words if > > the platform has no known limitation on the size of image, the zstd code > > should be indivisible to btrfs.mo. > > Wait, you said this in the commit message too: > > Therefore if the system has enough space of embedding area for grub then > zstd support for btrfs will be enabled automatically in the process of > running grub-install through inserting btrfs_zstd module to the on-disk > image, otherwise a warning will be logged on screen to indicate user > that zstd support for btrfs is disabled due to the size limit. > > So, I thought this may work in the same way in all cases. If this is not > true you have to fix this. Otherwise I cannot take this patch. I literally don't like to propagate this (somewhat awkward) fix to other architectures that do not have sensible requirement to it, though it looks possible to do so. If this doesn't meet the expection then I'm sorry. > > TBH, I should reject this patch immediately because this is "small MBR > gap stuff". And as I said a few months ago, I want to stop to pay > attention to "small MBR gap stuff" in upstream. Sorry for being blunt > but it is full can of worms, i.e., each patch like that one adds more > cruft which we have to take care because a few folks in the wild could > not spend a few hours to repartition their systems. I think distros > should start putting more effort in educating their users WRT to small > MBR gap and problems related to it instead of pushing again and again > upstream patches which make the GRUB code more complicated. Well, I think the short mbr gap issue is all well received been discussed several times. The reason I'm poking this beehive again is just that I can't resist to fix problem from our users who opted to use "btrfs partition" which differs to "short mbr gap" with a lot more user base and sensible usecases. FWIW we want to address this problem, because mbr gap is adjustable via re-partitioning but btrfs bootloader area is not. Thanks, Michael > > Daniel > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
