Re: [PATCH] Create a Containerfile with required grub packages for development

[Vladimir 'phcoder' Serbinenko]

I'm unsure about favouring one distro over the other on this.
Another thing: it misses arm and riscv efis in its package list

Regards
Vladimir 'phcoder' Serbinenko

Le lun. 9 juin 2025, 22:22, Leo Sandoval via Grub-devel 
a écrit :

> Containers bring the ability to have ready-to-use environments and in
> this case a complete Fedora container file is described containing
> all required packages for building and testing grub2.
>
> Once users manually build it, they can run the container jump into a
> setup ready for development. On the other hand, if users
> prefer to use bare metal instead of a containerized environment, it is
> still useful to have a file explicitly indicating the required packages.
> ---
>  container/Containerfile | 54 +
>  container/README| 14 +++
>  2 files changed, 68 insertions(+)
>  create mode 100644 container/Containerfile
>  create mode 100644 container/README
>
> diff --git a/container/Containerfile b/container/Containerfile
> new file mode 100644
> index 00..dd066a2ce1
> --- /dev/null
> +++ b/container/Containerfile
> @@ -0,0 +1,54 @@
> +FROM registry.fedoraproject.org/fedora
> +
> +# Install required packages
> +RUN dnf update -y && \
> +dnf install -y \
> +attr \
> +autoconf \
> +automake \
> +autopoint \
> +bison \
> +btrfs-progs \
> +cpio \
> +cryptsetup \
> +dosfstools \
> +e2fsprogs \
> +edk2-ovmf \
> +edk2-ovmf-ia32 \
> +erofs-utils \
> +exfatprogs \
> +f2fs-tools \
> +flex \
> +gawk \
> +gettext \
> +genromfs \
> +git \
> +hfsplus-tools \
> +jfsutils \
> +libtool \
> +lzop \
> +make \
> +mtools \
> +nilfs-utils \
> +ntfsprogs \
> +parted \
> +patch \
> +pkg-config \
> +python3 \
> +qemu-system-x86 \
> +squashfs-tools \
> +swtpm-tools \
> +tpm2-tools \
> +udftools \
> +unifont \
> +unifont-fonts \
> +which \
> +words \
> +xfsprogs \
> +xorriso \
> +zfs-fuse
> +
> +# clone tip of grub repository
> +RUN git clone --depth 1 https://https.git.savannah.gnu.org/git/grub.git
> /grub
> +
> +WORKDIR /grub
> \ No newline at end of file
> diff --git a/container/README b/container/README
> new file mode 100644
> index 00..788992abb9
> --- /dev/null
> +++ b/container/README
> @@ -0,0 +1,14 @@
> +install `podman` on your favorite distro then build it with
> +
> +$ podman build --tag grub .
> +
> +once built, you can run/launch it
> +
> +$ podman run -it grub
> +
> +and execute the standard build/test commands inside it
> +
> +# ./bootstrap
> +# ./configure
> +# ./make
> +# ./make check
> \ No newline at end of file
> --
> 2.48.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: QEMU and Grub.

[Vladimir 'phcoder' Serbinenko]

GRUB kernel doesn't have a stable interface. So it's not supported to mix
kernel and modules from different sources. What I do in your case is that I
use upstream kernel and modules with few patches to add blscfg. Those
patches are currently in review upstream

Regards
Vladimir 'phcoder' Serbinenko

Le sam. 7 juin 2025, 03:00, Shaun Reitan  a
écrit :

> I've asked this question in the past and just havn't been able to get an
> answer with a solution, or if I can even do what I want to do so I'm going
> to throw it out here again.
>
> I have a QEMU/KVM environment with flat disk images, no partitioning, no
> MBR, just a ext filesystem. These instances are not all the same and are
> running different OS's (RHEL, Ubuntu, etc). I'm wanting to boot these
> instances using grub, it's configs, and modules from the disk just the way
> it would if grub was installed onto the disk. So far I've been building
> grub images using grub-mkimage -O i386-pc -o grub.img biosdisk ext2 normal
> -p '(hd0)/boot/grub' and using the -kernel option with QEMU.  This does
> work but not always. There are some situations where i'm seeing errors like
> this.
>
> unaligned pointer 0x684355af
> Aborted. Press any key to exit.
>
> The reason I want to load grub, it's modules, and config from the disk is
> that distributions like redhat have decided to create modules like blscfg
> that are not part of grubs core and I need my grub image to load those from
> the disk so that the instance boots correctly.
>
> Can I do what I'm wanting to do? If so, how?  I don't want to have to
> build a bunch of grub versions to match each OS.
>
> --
> Shaun Reitan
>
>
>
> ___
> 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 0/1] Add Xen command line parsing

[Vladimir 'phcoder' Serbinenko]

I'm unsure about exporting all random parameters to env namespace. PHP went
down this road and result was bunch of bad vulnerabilities. Maybe instead
of blindly exporting it have some kind of export or query command? Or at
least add some prefix to exported vars to identify them as such?

Regards
Vladimir 'phcoder' Serbinenko

Le jeu. 24 avr. 2025, 05:47, Aaron Rainbolt  a écrit :

> The purpose of this patch is to allow the Xen hypervisor to pass extra
> data to GRUB in the form of a kernel command line, allowing the host to
> customize the boot process of the guest. The command line from Xen is
> parsed, and any variables within that start with the string
> `xen_grub_env_` are exposed as environment variables. The grub.cfg
> script can then use those environment variables as it sees fit.
>
> The main reason for doing this is to allow implementing boot modes in
> Qubes OS while also using in-VM kernels. For more context on Qubes boot
> modes, see [1]. In order for this to work with in-VM kernels, it is
> necessary for dom0 to pass kernel parameters to the guest without
> modifying the guest's grub.cfg manually. This patch allows this to be
> done, by allowing dom0 to pass kernel parameters to GRUB, which then
> provides them to grub.cfg as an environment variable. The grub.cfg
> script within the VM can then append those variables to the kernel
> command line.
>
> This is a significantly more robust version of the Xen command line
> parsing draft sent previously [2]. The patch has been tested with both
> PV and PVH virtual machines, using an otherwise unpatched GRUB source
> tree, building the patch on top of the tip of git master at the time
> of this writing (commit 4abac0a). My testing environment is a fully
> updated Arch Linux system with Xen built from the stable-4.20 branch.
>
> Some changes from the initial draft sent previously:
>
> * Only parameters starting with `xen_grub_env_` are exposed as
>   environment variables. This solves two of the previous patch's issues
>   - dom0 can no longer clobber arbitrary variables within grub.cfg (as
>   it cannot define variables with names that don't start with
>   `xen_grub_env`), and API breakage won't occur if in the future more
>   features are added to GRUB that use the Xen-provided kernel command
>   line.
> * Testing has been done as described above.
>
> [1] https://github.com/QubesOS/qubes-linux-pvgrub2/pull/16
> [2] https://lists.gnu.org/archive/html/grub-devel/2025-04/msg00050.html
>
> Aaron Rainbolt (1):
>   Add Xen command line parsing
>
>  grub-core/Makefile.core.def   |   2 +
>  grub-core/kern/i386/xen/pvh.c |  16 ++
>  grub-core/kern/main.c |  12 ++
>  grub-core/kern/xen/cmdline.c  | 270 ++
>  include/grub/xen.h|   2 +
>  5 files changed, 302 insertions(+)
>  create mode 100644 grub-core/kern/xen/cmdline.c
>
> --
> 2.49.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

Re: [RFC Discussion] Proposing an Unstable Repository for GRUB Development

[Vladimir 'phcoder' Serbinenko]

I appreciate your concern about pace of development and share them. However
maintaining what is effectively 2 versions is twice as much effort and
would only slow down both versions.
We are already discussing among maintainers how we can improve the state of
affairs but don't have anything ready for announcement.

Regards
Vladimir 'phcoder' Serbinenko

Le mar. 27 mai 2025, 22:39, Khalid Ali  a écrit :

> Hey GRUB community,
>
> This RFC discussion is about proposing a less stable repository alongside
> the current official one.
>
> The issue I'd like to raise is the slow pace of development. While this
> slow development helps ensure
> stability, it can also become a barrier to introducing new features, limit
> opportunities for improvement,
> and reduce long term project continuity.
>
> One potential solution I'd like to propose is to fork the current mainline
> stable repository and create a
> "development" or "unstable" repository. This repository could allow
> patches from contributors to be merged more quickly after
> careful review by project reviewers, of course.
>
> This would:
>  * Encourage broader community collaboration
>  * Allow contributors to gain more development experience
>  * Help us detect and fix bugs earlier, even before the RC (Release
> Candidate) phase
>
> The idea is not to compromise on stability, but to separate stable focused
> environments (like enterprise distributions)
> from bleeding-edge development. Distributions focused on stability could
> continue using the stable branch, while bleeding-edge
> distros could test the development branch and contribute feedback earlier.
>
> We could forward new features and experiments to the development
> repository, while routing critical fixes and security updates directly
> to the stable repository. In other words, we need to split GRUB into LTS
> and mainline or stable and unstable just like other modern
> software projects do. Which way we do it doesn't matter; what matters is
> that we open the door for faster, more flexible development.
> If my idea isn't the best fit, I encourage others to share theirs. I would
> also like to suggest that we adopt a fixed release schedule.
>
> I'm kindly reaching out to project maintainers, contributors, and others
> involved in GRUB to hear your thoughts on this idea.
> My observations come from spending time with the project and reflecting on
> how to keep it moving forward.
>
> Right now, we do an excellent job focusing on stability, bug fixes, and
> security which are all critical. But we also need to think
> about how to grow, how to innovate, and how to ensure GRUB stays strong
> into the future.
>
> Looking forward to your thoughts,
> Khaalid
>
>
> ___
> 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 2/3] Option to set title of submenus

[Vladimir 'phcoder' Serbinenko]

Why specifying the text as direct argument to menu entry not enough?
menuentry "Title" {

}

Regards
Vladimir 'phcoder' Serbinenko

Le mar. 27 mai 2025, 15:57, Jiří Wolker via Grub-devel 
a écrit :

> ---
>  grub-core/commands/menuentry.c | 47 ++
>  1 file changed, 47 insertions(+)
>
> diff --git a/grub-core/commands/menuentry.c
> b/grub-core/commands/menuentry.c
> index 720e6d8ea..c68afae38 100644
> --- a/grub-core/commands/menuentry.c
> +++ b/grub-core/commands/menuentry.c
> @@ -43,6 +43,9 @@ static const struct grub_arg_option options[] =
> anyone can boot it.  */
>  {"unrestricted", 0, 0, N_("This entry can be booted by any user."),
>   0, ARG_TYPE_NONE},
> +{"menutitle", 0, 0,
> + N_("Use STRING as menu title. When omitted, use the entry label."),
> + N_("TITLE"), ARG_TYPE_STRING},
>  {0, 0, 0, 0, 0, 0}
>};
>
> @@ -252,12 +255,44 @@ setparams_prefix (int argc, char **args)
>return result;
>  }
>
> +static char *
> +menutitle_prefix (char *old_prefix, const char *title)
> +{
> +  const char *t;
> +  char *p;
> +  char *result;
> +  grub_size_t len = 22;
> +  grub_size_t old_len = grub_strlen (old_prefix);
> +
> +  /* Count resulting string length. */
> +  for (t = title; *t; t++)
> +len += (*t++ == '\'' ? 4 : 1);
> +
> +  result = grub_malloc (old_len + len + 2);
> +  if (! result)
> +return 0;
> +
> +  p = result;
> +  grub_strcpy (p, old_prefix);
> +  p = result + old_len;
> +  grub_strcpy (p, "set grub_menu_title='");
> +  p += 21;
> +
> +  p = grub_strchrsub (p, title, '\'', "'\\''");
> +  *p++ = '\'';
> +  *p++ = '\n';
> +  *p = '\0';
> +
> +  return result;
> +}
> +
>  static grub_err_t
>  grub_cmd_menuentry (grub_extcmd_context_t ctxt, int argc, char **args)
>  {
>char ch;
>char *src;
>char *prefix;
> +  char *old_prefix;
>unsigned len;
>grub_err_t r;
>const char *users;
> @@ -299,6 +334,18 @@ grub_cmd_menuentry (grub_extcmd_context_t ctxt, int
> argc, char **args)
>if (! prefix)
>  return grub_errno;
>
> +  /* Prepend the menu title line. */
> +  if (ctxt->state[6].arg)
> +{
> +  old_prefix = prefix;
> +  prefix = menutitle_prefix (old_prefix, (ctxt->state[6].arg
> +&& grub_strlen (ctxt->state[6].arg) > 0)
> +? ctxt->state[6].arg : args[0]);
> +  if (! prefix)
> +   return grub_errno;
> +  grub_free (old_prefix);
> +}
> +
>r = grub_normal_add_menu_entry (argc - 1, (const char **) args,
>   ctxt->state[0].args, ctxt->state[4].arg,
>   users,
> --
> 2.45.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

Re: [PATCH 1/2] Exporting variables to upper levels

[Vladimir 'phcoder' Serbinenko]

Please explain what problem you try to solve. Bash doesn't do anything of
the kind. Why should we? Looks like a solution without a problem

Regards
Vladimir 'phcoder' Serbinenko

Le lun. 26 mai 2025, 20:34, Jiří 'bindiff' Wolker via Grub-devel <
grub-devel@gnu.org> a écrit :

> This adds new options ‘-g’ and ‘-u’ to the ‘export’ command.
>
> By default, the ‘export’ command exports the variables to
> lower environment context nesting levels, but not to the upper levels.
> This behavior is left unchanged from the original version.
>
> Using of the ‘-g’ option allows exporting of the given variable(s)
> even to the upper levels.
>
> The ‘-u’ option complements the default behavior of ‘export’ command:
> It causes the variable to become local, i.e., un-exported.
> ---
>   grub-core/kern/env.c   | 11 --
>   grub-core/normal/context.c | 70 ++
>   include/grub/env.h | 11 +-
>   3 files changed, 75 insertions(+), 17 deletions(-)
>
> diff --git a/grub-core/kern/env.c b/grub-core/kern/env.c
> index 764068896..6b60c71de 100644
> --- a/grub-core/kern/env.c
> +++ b/grub-core/kern/env.c
> @@ -231,7 +231,8 @@ grub_register_variable_hook (const char *name,
>   }
>grub_err_t
> -grub_env_export (const char *name)
> +grub_env_set_export_mode (const char *name,
> + enum grub_env_var_export mode)
>   {
> struct grub_env_var *var;
>   @@ -245,7 +246,13 @@ grub_env_export (const char *name)
> return err;
> var = grub_env_find (name);
>   }
> -  var->global = 1;
> +  var->global = mode;
>  return GRUB_ERR_NONE;
>   }
> +
> +grub_err_t
> +grub_env_export (const char *name)
> +{
> +  return grub_env_set_export_mode (name, grub_env_var_exported);
> +}
> diff --git a/grub-core/normal/context.c b/grub-core/normal/context.c
> index ba185e915..8abe5065c 100644
> --- a/grub-core/normal/context.c
> +++ b/grub-core/normal/context.c
> @@ -22,6 +22,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   #include 
>   #include 
>   @@ -88,7 +89,7 @@ grub_env_new_context (int export_all)
> grub_env_context_close ();
> return grub_errno;
>   }
> -   grub_env_export (var->name);
> +   grub_env_set_export_mode (var->name, var->global);
> grub_register_variable_hook (var->name, var->read_hook,
> var->write_hook);
>   }
>   }
> @@ -115,31 +116,52 @@ grub_err_t
>   grub_env_context_close (void)
>   {
> struct grub_env_context *context;
> +  struct grub_env_context *original_context;
> int i;
> struct menu_pointer *menu;
> +  grub_err_t last_err = GRUB_ERR_NONE;
>  if (! grub_current_context->prev)
>   return grub_error (GRUB_ERR_BAD_ARGUMENT,
>"cannot close the initial context");
>   -  /* Free the variables associated with this context.  */
> +  /* Restore the previous context.  */
> +  original_context = grub_current_context;
> +  context = grub_current_context->prev;
> +  grub_current_context = context;
> +
> +  /* Re-export global variables to the upper context. */
> +
> for (i = 0; i < HASHSZ; i++)
>   {
> struct grub_env_var *p, *q;
>   -  for (p = grub_current_context->vars[i]; p; p = q)
> +  for (p = original_context->vars[i]; p; p = q)
> {
>   q = p->next;
> +
> + /* Copy global variables to the upper context. */
> + if (p->global == grub_env_var_global) {
> +   if (grub_env_set (p->name, p->value) != GRUB_ERR_NONE)
> + {
> +   last_err = grub_errno;
> + }
> +   else
> + {
> +   grub_env_set_export_mode (p->name, p->global);
> +   grub_register_variable_hook (p->name, p->read_hook,
> p->write_hook);
> + }
> + }
> +
> + /* Free the variables associated with this context.  */
> grub_free (p->name);
>   grub_free (p->value);
>   grub_free (p);
> }
>   }
>   -  /* Restore the previous context.  */
> -  context = grub_current_context->prev;
> -  grub_free (grub_current_context);
> -  grub_current_context = context;
> +  /* Free the previous context. */
> +  grub_free (original_context);
>  menu = current_menu->prev;
> if (current_menu->menu)
> @@ -181,34 +203,54 @@ grub_env_extractor_close (int source)
> return err;
>   }
>   -static grub_command_t export_cmd;
> +static grub_extcmd_t export_cm

Re: [PATCH v2 2/2] cmdline: fix command line parsing in grub

[Vladimir 'phcoder' Serbinenko]

Here is the patch in question:
https://lists.gnu.org/archive/html/grub-devel/2023-07/msg00089.html. It
will need an additional change to Linux calling.

Regards
Vladimir 'phcoder' Serbinenko

Le ven. 23 mai 2025, 19:53, Shreenidhi Shedi  a écrit :

> On 20/05/25 19:15, Daniel Kiper wrote:
> > On Mon, May 19, 2025 at 11:49:55PM +0530, Shreenidhi Shedi wrote:
> >> From: Shreenidhi Shedi 
> >>
> >> Previously, the command line construction function
> >> (grub_create_loader_cmdline) escaped single and double quotes, which is
> >> unnecessary and potentially problematic since the kernel command line
> >> handler does not support escaped quotes. This patch removes the escaping
> >> of these characters, ensuring that the constructed command line is
> >> passed to the kernel as intended.
> >>
> >> For example:
> >>
> >> In /boot/grub/grub.cfg
> >> ...
> >> set user_cmdline="dyndbg='+p; func smp_callin -p'"
> >> ...
> >> menuentry "Photon" {
> >>linux /boot/$photon_linux root=$rootpartition $photon_cmdline
> $systemd_cmdline $user_cmdline
> >>if [ -f /boot/$photon_initrd ]; then
> >>  initrd /boot/$photon_initrd
> >>fi
> >> }
> >> ...
> >>
> >> Post reboot,
> >>
> >> $ cat /proc/cmdline
> >> ... dyndbg=\'+p; func smp_callin -p\'
> >
> > AFIACT Vladimir has more complete fix for this issue. I asked him to
> > post it once again...
> >
> > Daniel
>
> Hi Daniel,
>
> Can you please add Vladimir to this thread? This is a regression and if
> we can get a better fix, I can test it and provide an update.
>
> --
> Shedi
>
> ___
> 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/4] fs/ntfs: Correct regression with run list calculation

[Vladimir 'phcoder' Serbinenko]

Reviewed-by: Vladimir Serbinenko 

Regards
Vladimir 'phcoder' Serbinenko

Le mar. 20 mai 2025, 05:03, Andrew Hamilton  a écrit :

> Correct ntfs_test test failures around attempting to validate attribute
> run list values. The calculation was incorrect for the 'curr' variable.
> With previous calculation, some file systems would fail validation
> despite being well-formed and valid. This was caused by incrementing
> 'curr' by min_size which included both the (already accounted for)
> min_size as well as the size of the run list. Correct by making a new
> variable 'run_size' to denote the current run list size to increment
> both 'curr' and 'min_size' separately.
>
> Fixes: 067b6d225 (fs/ntfs: Implement attribute verification)
>
> Signed-off-by: Andrew Hamilton 
> ---
>  grub-core/fs/ntfs.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/grub-core/fs/ntfs.c b/grub-core/fs/ntfs.c
> index b3117bf92..3eb70111b 100644
> --- a/grub-core/fs/ntfs.c
> +++ b/grub-core/fs/ntfs.c
> @@ -83,6 +83,7 @@ validate_attribute (grub_uint8_t *attr, void *end)
>  {
>grub_size_t attr_size = 0;
>grub_size_t min_size = 0;
> +  grub_size_t run_size = 0;
>grub_size_t spare = (grub_uint8_t *) end - attr;
>/*
> * Just used as a temporary variable to try and deal with cases where
> someone
> @@ -174,8 +175,10 @@ validate_attribute (grub_uint8_t *attr, void *end)
>* These directly follow the header byte, so we use them to
> update
>* the minimum size.
>*/
> - min_size += (attr[curr] & 0x7) + ((attr[curr] >> 4) & 0x7);
> - curr += min_size;
> + run_size = (attr[curr] & 0x7) + ((attr[curr] >> 4) & 0x7);
> + curr += run_size;
> + curr++;
> + min_size += run_size;
>   min_size++;
>   if (min_size > attr_size)
> goto fail;
> --
> 2.39.5
>
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v1 1/2] envblk: ignore empty new lines while parsing env files

[Vladimir 'phcoder' Serbinenko]

Are those empty lines result of manual editing of envblk? You should not do
this

Regards

Le dim. 18 mai 2025, 11:01, Shreenidhi Shedi  a écrit :

> From: Shreenidhi Shedi 
>
> Environment files may contain empty lines, which should be
> ignored during parsing. Currently, these lines are not skipped and
> resulting in incorrect behavior. This patch adds a check to skip empty
> lines along with those starting with `#'.
>
> Signed-off-by: Shreenidhi Shedi 
> Reviewed-by: Alexey Makhalov  
> ---
>  grub-core/lib/envblk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/grub-core/lib/envblk.c b/grub-core/lib/envblk.c
> index 2e4e78b13..f08dabaad 100644
> --- a/grub-core/lib/envblk.c
> +++ b/grub-core/lib/envblk.c
> @@ -235,7 +235,7 @@ grub_envblk_iterate (grub_envblk_t envblk,
>
>while (p < pend)
>  {
> -  if (*p != '#')
> +  if (*p != '#' && *p != '\n')
>  {
>char *name;
>char *value;
> --
> 2.49.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

Re: [PATCH 2/3] fs/fshelp: Avoid possible NULL pointer deference

[Vladimir 'phcoder' Serbinenko]

Another comment: ERR_BAD_FS might be a better fit given how it can be
triggered.

Regards

Le sam. 17 mai 2025, 14:09, Vladimir 'phcoder' Serbinenko 
a écrit :

>
> Small comment, otherwise looks good
>
> Le sam. 17 mai 2025, 04:26, Andrew Hamilton  a écrit :
>
>> Avoid attempting to defererence a NULL pointer to call read_symlink when
>> the given filesystem does not provide a read_symlink function. This could
>> be triggered if the calling filesystem had a file marked as a symlink.
>> This appears possible for HFS and was observed during fuzzing of NTFS.
>>
>> Signed-off-by: Andrew Hamilton 
>> ---
>>  grub-core/fs/fshelp.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/grub-core/fs/fshelp.c b/grub-core/fs/fshelp.c
>> index cb41934b4..a9d24a908 100644
>> --- a/grub-core/fs/fshelp.c
>> +++ b/grub-core/fs/fshelp.c
>> @@ -226,7 +226,10 @@ find_file (char *currpath,
>> return grub_error (GRUB_ERR_SYMLINK_LOOP,
>>N_("too deep nesting of symlinks"));
>>
>> - symlink = read_symlink (ctx->currnode->node);
>> + if (read_symlink != NULL)
>> +   symlink = read_symlink (ctx->currnode->node);
>> + else
>> +   return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("read_symlink is
>> NULL"));
>>
>
> Not worth translating. Otherwise
> Reviewed-by: Vladimir Serbinenko 
>
>>
>>   if (!symlink)
>> return grub_errno;
>> --
>> 2.39.5
>>
>>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 2/3] fs/fshelp: Avoid possible NULL pointer deference

[Vladimir 'phcoder' Serbinenko]

Small comment, otherwise looks good

Le sam. 17 mai 2025, 04:26, Andrew Hamilton  a écrit :

> Avoid attempting to defererence a NULL pointer to call read_symlink when
> the given filesystem does not provide a read_symlink function. This could
> be triggered if the calling filesystem had a file marked as a symlink.
> This appears possible for HFS and was observed during fuzzing of NTFS.
>
> Signed-off-by: Andrew Hamilton 
> ---
>  grub-core/fs/fshelp.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/fs/fshelp.c b/grub-core/fs/fshelp.c
> index cb41934b4..a9d24a908 100644
> --- a/grub-core/fs/fshelp.c
> +++ b/grub-core/fs/fshelp.c
> @@ -226,7 +226,10 @@ find_file (char *currpath,
> return grub_error (GRUB_ERR_SYMLINK_LOOP,
>N_("too deep nesting of symlinks"));
>
> - symlink = read_symlink (ctx->currnode->node);
> + if (read_symlink != NULL)
> +   symlink = read_symlink (ctx->currnode->node);
> + else
> +   return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("read_symlink is
> NULL"));
>

Not worth translating. Otherwise
Reviewed-by: Vladimir Serbinenko 

>
>   if (!symlink)
> return grub_errno;
> --
> 2.39.5
>
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2] testpci: initial module

[Vladimir 'phcoder' Serbinenko]

Looks good
Reviewed-by: Vladimir Serbinenko phco...@gmail.com

Regards
Vladimir 'phcoder' Serbinenko

Le lun. 12 mai 2025, 14:55, Yair Yarom  a écrit :

> Initial testpci module and command used to query if PCI devices are
> present.
>
> ---
>  docs/grub.texi   |  39 +++
>  grub-core/Makefile.core.def  |   7 ++
>  grub-core/commands/testpci.c | 194 +++
>  grub-core/kern/efi/sb.c  |   1 +
>  include/grub/file.h  |   2 +
>  5 files changed, 243 insertions(+)
>  create mode 100644 grub-core/commands/testpci.c
>
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 2b3d536d3..a5712012e 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -4139,6 +4139,7 @@ Modules can be loaded via the @command{insmod}
> (@pxref{insmod}) command.
>  * test_module::
>  * test_blockarg_module::
>  * testload_module::
> +* testpci_module::
>  * testspeed_module::
>  * tftp_module::
>  * tga_module::
> @@ -5728,6 +5729,12 @@ argument function in GRUB internal functions via a
> test command
>  This module is intended for performing a functional test of some file
> reading /
>  seeking functions in GRUB internals via a test command @command{testload}.
>
> +@node testpci_module
> +@section testpci
> +This module provides support for the @command{testpci} command. This
> +command can be used to test if specific PCI / PCIe devices are found on
> +the system.
> +
>  @node testspeed_module
>  @section testspeed
>  This module provides support for the @command{testspeed} command to test
> and
> @@ -8052,6 +8059,38 @@ either @var{expression1} or @var{expression2} is
> true
>  @end table
>  @end deffn
>
> +@node testpci
> +@subsection testpci
> +
> +@deffn Command testpci [@option{--file} device.lst] [@var{device} [...]]
> +Test if a PCI device is present.
> +
> +Gets a device list to check from command line arguments, and/or from the
> +@var{device.lst} file.
> +
> +If any of the devices in the list are present on the machine - the
> +command exits with zero status.
> +
> +If the list is empty; Or non of the devices in the list are present; Or
> +any error occurred (bad device format, missing file, memory, etc.) - a
> +non-zero exit code is returned.
> +
> +Each @var{device} should be in the format @code{:}, where
> +@code{} is the vendor id, and @code{} is the device id. All
> +lower case as appear in the output of the @command{lspci} command.
> +
> +If @var{device.lst} file is given, each line should contain a single
> +@var{device}. Space padding, comments starting with #, and empty lines
> +are ignored.
> +
> +For example:
> +@example
> +if testpci --file $prefix/device.lst 10de:233b 1002:74a5; then
> +   set somevar=somevalue
> +fi
> +@end example
> +@end deffn
> +
>  @node tpm2_key_protector_init
>  @subsection tpm2_key_protector_init
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index f70e02e69..f18d2304d 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -1032,6 +1032,13 @@ module = {
>enable = pci;
>  };
>
> +module = {
> +  name = testpci;
> +  common = commands/testpci.c;
> +
> +  enable = pci;
> +};
> +
>  module = {
>name = memrw;
>common = commands/memrw.c;
> diff --git a/grub-core/commands/testpci.c b/grub-core/commands/testpci.c
> new file mode 100644
> index 0..8af2a57a2
> --- /dev/null
> +++ b/grub-core/commands/testpci.c
> @@ -0,0 +1,194 @@
> +/* testpci.c - Test if PCI exists by ID.  */
> +/*
> + *  GRUB  --  GRand Unified Bootloader
> + *  Copyright (C) 2025  Free Software Foundation, Inc.
> + *
> + *  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 <http://www.gnu.org/licenses/>.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +GRUB_MOD_LICENSE ("GPLv3+");
> +
> +static const struct grub_arg_option options[] = {
> +  {"file", 'f', 0, "read device list from file", "FILE", 

Re: [PATCH v5] commands/efi: dump all uefi runtime variables

[Vladimir 'phcoder' Serbinenko]

Le lun. 12 mai 2025, 10:37, khaalid cali  a écrit :

> From: khaalid 
>
> > Vladimir 'phcoder' Serbinenko wrote:
> > Please have a look at how to handle errors with realloc. You need to
> keep a copy of old pointer in case you have to free it. Some places in our
> codebase have similar memory leaks but it'> s not a reason to introduce
> more.
>
> Well, i followed style used on codebase mostly. And now fine.
>
> Signed-off-by: Khalid Ali 
> ---
>  grub-core/Makefile.core.def   |   6 ++
>  grub-core/commands/efi/lsefivar.c | 139 ++
>  2 files changed, 145 insertions(+)
>  create mode 100644 grub-core/commands/efi/lsefivar.c
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index f70e02e69..8b9cf2a68 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -840,6 +840,12 @@ module = {
>enable = efi;
>  };
>
> +module = {
> +  name = lsefivar;
> +  efi = commands/efi/lsefivar.c;
> +  enable = efi;
> +};
> +
>  module = {
>name = blocklist;
>common = commands/blocklist.c;
> diff --git a/grub-core/commands/efi/lsefivar.c
> b/grub-core/commands/efi/lsefivar.c
> new file mode 100644
> index 0..d18ca296b
> --- /dev/null
> +++ b/grub-core/commands/efi/lsefivar.c
> @@ -0,0 +1,139 @@
> +/* efivar.c - dump runtime uefi variables. */
> +/*
> + *  GRUB  --  GRand Unified Bootloader
> + *  Copyright (C) 2025  Free Software Foundation, Inc.
> + *
> + *  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 <http://www.gnu.org/licenses/>.
> + */
> +
> +
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +GRUB_MOD_LICENSE ("GPLv3+");
> +
> +static const struct grub_arg_option options[] =
> +{
> +   {0, 'l', 0, N_("Dump variable contents"), 0, 0},
> +   {0, 0, 0, 0, 0, 0}
> +};
> +
> +static void
> +dump_variable_data(const char *variable_name, grub_guid_t *variable_guid)
> +{
> +grub_efi_status_t status;
> +grub_efi_uint32_t attributes;
> +grub_size_t data_size;
> +void *data;
> +
> +status = grub_efi_get_variable_with_attributes(variable_name,
> variable_guid,
> +   &data_size, &data,
> &attributes);
> +if (status != GRUB_EFI_SUCCESS)
> +{
> +grub_error(GRUB_ERR_IO, "failed to retrieve variable data 0x%"
> PRIxGRUB_EFI_UINTN_T, status);
> +grub_errno = GRUB_ERR_NONE;
>
Do not call grub_error here.

> +return;
> +}
> +
> +grub_puts_("Attributes:\n");
>
Puts_(N_(...))
Having to put N_ is unfortunate and I might fix it separately but for now,
is necessary.

> +if (attributes & GRUB_EFI_VARIABLE_NON_VOLATILE)
> +grub_printf(_("\tNon-Volatile\n"));
>
puts_

> +if (attributes & GRUB_EFI_VARIABLE_BOOTSERVICE_ACCESS)
> +grub_printf(_("\tBoot Service Access\n"));
> +if (attributes & GRUB_EFI_VARIABLE_RUNTIME_ACCESS)
> +grub_printf(_("\tRuntime Service Access\n"));
> +
> +grub_printf(_("Value:\n"));
> +hexdump(0, data, data_size);
> +grub_free(data);
> +}
> +
> +static grub_err_t
> +dump_efi_variables(void)
> +{
> +   grub_efi_status_t status;
> +   grub_efi_runtime_services_t *r;
> +   grub_efi_uintn_t variable_name_size = 512;
> +   grub_efi_char16_t *variable_name;
> +   grub_uint8_t *variable_name_string = NULL;
> +   grub_guid_t vendor_guid;
> +
> +   r = grub_efi_system_table->runtime_services;
> +
> +   variable_name = grub_calloc(variable_name_size,
> sizeof(grub_efi_char16_t));
> +   if (variable_name == NULL)
> +   return grub_errno;
> +   *variable_name = 0; /* Start with empty string */
> +
> +   while (1)
> +   {
> +   status = r->get_next_variable_name(&variable_name_size,

Re: [PATCH] testpci: initial module

[Vladimir 'phcoder' Serbinenko]

Le dim. 11 mai 2025, 17:11, Yair Yarom  a écrit :

>
>
> On Thu, 8 May 2025 at 17:30, Vladimir 'phcoder' Serbinenko <
> phco...@gmail.com> wrote:
>
>> Le jeu. 8 mai 2025, 15:49, Yair Yarom  a écrit :
>>
>>> +#include 
>>>
>> What requires normal.h? Just curious
>>
> grub_file_getline is in normal.h
>
Sounds good.

>
>
>
>> +grub_file_t listfile = grub_file_open(ctxt->state[0].arg,
>>> GRUB_FILE_TYPE_NONE);
>>>
>> File type is wrong
>>
> What should be the file type? Should I create a new one (e.g.
> GRUB_FILE_TYPE_DEVICE_LIST) ? If so, should I add it to
> shim_lock_verifier_init? (we don't use secure boot, and I'm less familiar
> with it)
>
Create a new one. This type should be handled same way as TYPE_HEXDUMP

>
> Thanks,
> Yair.
> ___
> 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] commands/efi: add command to dump all uefi runtime variables

[Vladimir 'phcoder' Serbinenko]

Le dim. 11 mai 2025, 17:36, khaalid cali  a écrit :

> From: khaalid 
>
> I followed the suggestion and implemented the option parsing using extcmd.
> However, I feel this command is not ideal to have any arguments. Similar
> commands like
> lsefi, lsefimmap, and lsefisystab don’t take arguments—they simply dump
> data.
> Since this command also just dumps variables and doesn’t do anything more,
> adding options might introduce inconsistency.
>
> Returning grub_err_t for `dump_variable_data` isn't ideal neither for
> two reasons:
>  - First the only place the function fail is if
> `grub_efi_get_variable_with_attributes`
>fail; this function returns EFI_STATUS mostly, so even if it fails and
> sets errno then
>`grub_error` already overrided it so we get GRUB_ERR_IO always.
>  - Second `dump_variable_data` is expected to fail because not every
>variable can neccessarily retrieved, some will fail due security
> restrictions. So it is better
>if we skip failed variables and move on to the next one.
>
If you want to ignore error, you need to reset grub_errno to GRUB_ERR_NONE,
not call grub_error. Then you can keep it void

>
> +static void
> +dump_variable_data(const char *variable_name, grub_guid_t *variable_guid)
> +{
> +grub_efi_status_t status;
> +grub_efi_uint32_t attributes;
> +grub_size_t data_size;
> +void *data;
> +
> +status = grub_efi_get_variable_with_attributes(variable_name,
> variable_guid,
> +   &data_size, &data,
> &attributes);
> +if (status != GRUB_EFI_SUCCESS)
> +{
> +grub_error(GRUB_ERR_IO, "failed to retrieve variable data 0x%"
> PRIxGRUB_EFI_UINTN_T, status);
>
Already said.

+return;
> +}
> +
> +grub_printf(_("Attributes:\n"));
>
Actually grub_puts_ is preferred when they're are no arguments. Sorry, I
forgot this.

> +   variable_name = grub_realloc(variable_name,
> variable_name_size * sizeof(grub_efi_char16_t));
> +   if (variable_name == NULL)
>
Please have a look at how to handle errors with realloc. You need to keep a
copy of old pointer in case you have to free it. Some places in our
codebase have similar memory leaks but it's not a reason to introduce more.

> +   return grub_errno;
> +   }
>
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v3] commands/efi: add command to dump all uefi runtime variables

[Vladimir 'phcoder' Serbinenko]

>
>
>
> Changes in v3:
>   - Command arguments, maybe this command is better if it doesn't have
> any command argument, since we are printing only. Command options is
> just unneccessary. And this is how many grub commands does, so it
> should align.
>
Options are good. Just use extcmd to parse them, not manual parsing.

+static void
>
Better to return grub_err_t here and properly propagate it

> +dump_variable_data(const char *variable_name, grub_guid_t *variable_guid)
> +{
> +grub_efi_status_t status;
> +grub_efi_uint32_t attributes;
> +grub_size_t data_size;
> +void *data;
> +
> +status = grub_efi_get_variable_with_attributes(variable_name,
> variable_guid,
> +   &data_size, &data,
> &attributes);
> +if (status != GRUB_EFI_SUCCESS)
> +{
> +grub_error(GRUB_ERR_IO, "failed to retrieve variable data 0x%"
> PRIxGRUB_EFI_UINTN_T, status);
> +return;
> +}
> +
> +grub_printf(_("Attributes:\n"));
> +if (attributes & GRUB_EFI_VARIABLE_NON_VOLATILE)
> +grub_printf(_("\tNon-Volatile\n"));
> +if (attributes & GRUB_EFI_VARIABLE_BOOTSERVICE_ACCESS)
> +grub_printf(_("\tBoot Service Access\n"));
> +if (attributes & GRUB_EFI_VARIABLE_RUNTIME_ACCESS)
> +grub_printf(_("\tRuntime Service Access\n"));
> +
> +grub_printf(_("Value:\n"));
> +hexdump(0, data, data_size);
> +grub_free(data);
> +}
> +
> +static grub_err_t
> +dump_efi_variables(void)
> +{
> +   grub_efi_status_t status;
> +   grub_efi_runtime_services_t *r;
> +   grub_efi_uintn_t variable_name_size = 512;
> +   grub_efi_char16_t *variable_name;
> +   grub_uint8_t *variable_name_string = NULL;
> +   grub_guid_t vendor_guid;
> +
> +   r = grub_efi_system_table->runtime_services;
> +
> +   variable_name = grub_calloc(variable_name_size,
> sizeof(grub_efi_char16_t));
> +   if (variable_name == NULL)
> +   return grub_errno;
> +   *variable_name = 0; /* Start with empty string */
> +
> +   while (1)
> +   {
> +   status = r->get_next_variable_name(&variable_name_size,
> variable_name, &vendor_guid);
> +   if (status == GRUB_EFI_NOT_FOUND)
> +   break;
> +   else if (status == GRUB_EFI_BUFFER_TOO_SMALL)
> +   {
> +   grub_dprintf("lsefivar", "buffer isn't enough,
> enlarging up to %ld bytes\n",variable_name_size *
> sizeof(grub_efi_char16_t));
> +   variable_name = grub_realloc(variable_name,
> variable_name_size * sizeof(grub_efi_char16_t));
> +   if (variable_name == NULL)
> +   {
> +   grub_free(variable_name);
>
This free of NULL does absolutely nothing. Please fix it.

> +   return grub_errno;
> +   }
> +   }
> +   variable_name_string = grub_calloc(variable_name_size,
> GRUB_MAX_UTF8_PER_UTF16);
>
This is not enough. You need 1 byte more.

> +   if (variable_name_string == NULL)
> +   {
> +   grub_free(variable_name);
> +   return grub_errno;
> +   }
> +   *grub_utf16_to_utf8(variable_name_string, variable_name,
> variable_name_size) = '\0';
> +   grub_printf("%pG-%s\n",&vendor_guid, variable_name_string);
> +   dump_variable_data((char*)variable_name_string,
> &vendor_guid);
> +   }
> +
> +   grub_free(variable_name);
> +   if (variable_name_string)
> +   grub_free(variable_name_string);
>
grub_free already checks for null.

+   return GRUB_ERR_NONE;
> +}
> +
> +static grub_err_t
> +grub_cmd_lsefivar (grub_command_t cmd __attribute__((unused)),
> +int argc __attribute__((unused)), char **argv
> __attribute__((unused)))
> +{
> +   return dump_efi_variables();
>
As I said: options and extcmd. Like normal ls command

> +}
> +
> +static grub_command_t cmd;
> +
> +GRUB_MOD_INIT(lsefivar)
> +{
> +   cmd = grub_register_command("lsefivar", grub_cmd_lsefivar, NULL,
> N_("Display UEFI variables."));
> +}
> +GRUB_MOD_FINI(lsefivar)
> +{
> +   grub_unregister_command(cmd);
> +}
> +
> +
> --
> 2.49.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

Re: [PATCH v2] commands/efi: add a command to dump all uefi runtime variables

[Vladimir 'phcoder' Serbinenko]

>
>
>  - About error handling i changed a place being suggested to change
>GRUB_ERR_BAD_MODULE, i changed to GRUB_ERR_BUG

ERR_BUG is for an internal bugs aka should never happen. ERR_IO is a better
possibility.

> +
> +
> +static void
> +dump_variable_data(const char *variable_name, grub_guid_t *variable_guid)
> +{
> +grub_efi_status_t status;
> +grub_efi_uint32_t attributes;
> +grub_size_t data_size;
> +void *data;
> +
> +status = grub_efi_get_variable_with_attributes(variable_name,
> variable_guid,
> +   &data_size, &data,
> &attributes);
> +if (status != GRUB_EFI_SUCCESS)
> +{
> +grub_error(GRUB_ERR_BUG, "Failed to retrieve variable data 0x%"
> PRIxGRUB_EFI_UINTN_T, status);
>
Error messages start with lowercase.

+return;
> +}
> +
> +grub_printf("Attributes:\n");
>
Needs translation

> +if (attributes & GRUB_EFI_VARIABLE_NON_VOLATILE)
> +grub_printf(N_("\tNon-Volatile\n"));
>
N_ doesn't translate, only marks for translation. You need to use printf_
or simple _. Here and following.

> +
> +   variable_name = grub_malloc(variable_name_size);
>
Here and in following: buffer size is in char16s, not bytes, so you need to
use calloc with size argument equal to size of(char16s)

> +   if (!variable_name)
> +   return grub_errno;
> +   *variable_name = 0; /* Start with empty string */
> +
> +   while (1)
> +   {
> +   status = r->get_next_variable_name(&variable_name_size,
> variable_name, &vendor_guid);
> +   if (status == GRUB_EFI_NOT_FOUND)
> +   break;
>
You don't handle EFI_BUFFER_TOO_SMALL

> +   variable_name_string = grub_realloc(variable_name_string,
> variable_name_size);

You need variable_name_size * GRUB_MAX_UTF8_PER_UTF16 + 1 bytes to hold
UTF-8 string.

> +   if (variable_name_string == NULL)
> +   return grub_errno;
>
Here you have a memory leak

> +   grub_utf16_to_utf8(variable_name_string, variable_name,
> variable_name_size);
>
You need to set last char to \0. Look at other users

> +   grub_printf("%pG-%s\n",&vendor_guid, variable_name_string);
> +   dump_variable_data((char*)variable_name_string,
> &vendor_guid);
> +   }
> +
> +   grub_free(variable_name);
> +   grub_free(variable_name_string);
> +   return GRUB_ERR_NONE;
> +}
> +
> +static grub_err_t
> +grub_cmd_lsefivar (grub_command_t cmd __attribute__((unused)),
> +int argc , char **argv)
> +{
> +   if (argc == 0)
> +   {
> +   grub_printf("Usage: lsefivar [-l]\n");
> +   return GRUB_ERR_BAD_ARGUMENT;
> +   }
>
Please use extcmd for argument parsing and documentation

> +   if (!grub_strcmp(argv[0], "-l"))
> +   return dump_efi_variables();
> +
> +   return GRUB_ERR_NONE;
> +}
> +
> +static grub_command_t cmd;
> +
> +GRUB_MOD_INIT(lsefivar)
> +{
> +   cmd = grub_register_command("lsefivar", grub_cmd_lsefivar, NULL,
> N_("Display UEFI variables."));
> +}
> +GRUB_MOD_FINI(lsefivar)
> +{
> +   grub_unregister_command(cmd);
> +}
> --
> 2.49.0
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [SECURITY PATCH 2/8] commands/search: Introduce the --cryptodisk-only argument

[Vladimir 'phcoder' Serbinenko]

Small nitpick, otherwise
Reviewed-by: Vladimir Serbinenko phco...@gmail.com

Le jeu. 8 mai 2025, 20:03, Daniel Kiper via Grub-devel 
a écrit :

> From: Maxim Suhanov 
>
> This allows users to restrict the "search" command's scope to
> encrypted disks only.
>
> Typically, this command is used to "rebase" $root and $prefix
> before loading additional configuration files via "source" or
> "configfile". Unfortunately, this leads to security problems,
> like CVE-2023-4001, when an unexpected, attacker-controlled
> device is chosen by the "search" command.
>
> The --cryptodisk-only argument allows users to ensure that the
> file system picked is encrypted.
>
> This feature supports the CLI authentication, blocking bypass
> attempts.
>
> Signed-off-by: Maxim Suhanov 
> Reviewed-by: Daniel Kiper 
> ---
>  grub-core/commands/search.c  | 20 
>  grub-core/commands/search_wrap.c |  7 ++-
>  grub-core/normal/main.c  |  3 ++-
>  include/grub/search.h|  7 ---
>  4 files changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/grub-core/commands/search.c b/grub-core/commands/search.c
> index 263f1501c..f6bfef958 100644
> --- a/grub-core/commands/search.c
> +++ b/grub-core/commands/search.c
> @@ -86,6 +86,26 @@ iterate_device (const char *name, void *data)
>grub_device_close (dev);
>  }
>
> +  /* Limit to encrypted disks when requested. */
> +  if (ctx->flags & SEARCH_FLAGS_CRYPTODISK_ONLY)
> +{
> +  grub_device_t dev;
> +
> +  dev = grub_device_open (name);
> +  if (dev == NULL)
> +   {
> + grub_errno = GRUB_ERR_NONE;
> + return 0;
> +   }
> +  if (dev->disk == NULL || dev->disk->dev->id !=
> GRUB_DISK_DEVICE_CRYPTODISK_ID)
> +   {
> + grub_device_close (dev);
> + grub_errno = GRUB_ERR_NONE;
>
I think this grub_errno setting is redundant as device_open succeeded

> + return 0;
> +   }
> +  grub_device_close (dev);
> +}
> +
>  #ifdef DO_SEARCH_FS_UUID
>  #define compare_fn grub_strcasecmp
>  #else
> diff --git a/grub-core/commands/search_wrap.c
> b/grub-core/commands/search_wrap.c
> index 318581f3b..5f536006c 100644
> --- a/grub-core/commands/search_wrap.c
> +++ b/grub-core/commands/search_wrap.c
> @@ -41,6 +41,7 @@ static const struct grub_arg_option options[] =
>   ARG_TYPE_STRING},
>  {"no-floppy",  'n', 0, N_("Do not probe any floppy drive."), 0,
> 0},
>  {"efidisk-only",   0, 0, N_("Only probe EFI disks."), 0, 0},
> +{"cryptodisk-only",0, 0, N_("Only probe encrypted disks."),
> 0, 0},
>  {"hint",   'h', GRUB_ARG_OPTION_REPEATABLE,
>   N_("First try the device HINT. If HINT ends in comma, "
> "also try subpartitions"), N_("HINT"), ARG_TYPE_STRING},
> @@ -75,6 +76,7 @@ enum options
>  SEARCH_SET,
>  SEARCH_NO_FLOPPY,
>  SEARCH_EFIDISK_ONLY,
> +SEARCH_CRYPTODISK_ONLY,
>  SEARCH_HINT,
>  SEARCH_HINT_IEEE1275,
>  SEARCH_HINT_BIOS,
> @@ -189,6 +191,9 @@ grub_cmd_search (grub_extcmd_context_t ctxt, int argc,
> char **args)
>if (state[SEARCH_EFIDISK_ONLY].set)
>  flags |= SEARCH_FLAGS_EFIDISK_ONLY;
>
> +  if (state[SEARCH_CRYPTODISK_ONLY].set)
> +flags |= SEARCH_FLAGS_CRYPTODISK_ONLY;
> +
>if (state[SEARCH_LABEL].set)
>  grub_search_label (id, var, flags, hints, nhints);
>else if (state[SEARCH_FS_UUID].set)
> @@ -210,7 +215,7 @@ GRUB_MOD_INIT(search)
>cmd =
>  grub_register_extcmd ("search", grub_cmd_search,
>   GRUB_COMMAND_FLAG_EXTRACTOR |
> GRUB_COMMAND_ACCEPT_DASH,
> - N_("[-f|-l|-u|-s|-n] [--hint HINT [--hint HINT]
> ...]"
> + N_("[-f|-l|-u|-s|-n] [--cryptodisk-only] [--hint
> HINT [--hint HINT] ...]"
>  " NAME"),
>   N_("Search devices by file, filesystem label"
>  " or filesystem UUID."
> diff --git a/grub-core/normal/main.c b/grub-core/normal/main.c
> index 04d058f55..96abfda2f 100644
> --- a/grub-core/normal/main.c
> +++ b/grub-core/normal/main.c
> @@ -511,7 +511,8 @@ static const char *features[] = {
>"feature_chainloader_bpb", "feature_ntldr",
> "feature_platform_search_hint",
>"feature_default_font_path", "feature_all_video_module",
>"feature_menuentry_id", "feature_menuentry_options",
> "feature_200_final",
> -  "feature_nativedisk_cmd", "feature_timeout_style"
> +  "feature_nativedisk_cmd", "feature_timeout_style",
> +  "feature_search_cryptodisk_only"
>  };
>
>  GRUB_MOD_INIT(normal)
> diff --git a/include/grub/search.h b/include/grub/search.h
> index ffd2411ca..3eabaf0cc 100644
> --- a/include/grub/search.h
> +++ b/include/grub/search.h
> @@ -21,9 +21,10 @@
>
>  enum search_flags
>{
> -SEARCH_FLAGS_NONE  = 0,
> -SEARCH_FLAGS_NO_FLOPPY = 1,
> -SEARCH_FLAGS_EFIDISK_ONLY  = 2
> +SEARCH_FLAGS_NONE= 0,
> +SEARCH_FLAGS_NO_FLOPPY   = 1,
> +SEAR

Re: [RFC PATCH] commands/efi: add a command to dump all UEFI runtime variables

[Vladimir 'phcoder' Serbinenko]

Le ven. 9 mai 2025, 13:15, khaalid cali  a écrit :

> From: khaalid 
>
> This command is intended to print or dump all UEFI runtime services.
> The structure will look like efivar tool, since visually most people are
> familiar with it. If the variable content is string then dump it as
> string, otherwise for non string variables print them as raw hex; just
> the way efivar command does.
>
> Signed-off-by: khaalid 
>
Please use correct legal name in sign off.

> ---
>  grub-core/Makefile.core.def |   6 ++
>  grub-core/commands/efi/efivar.c | 150 
>  2 files changed, 156 insertions(+)
>  create mode 100644 grub-core/commands/efi/efivar.c
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index f70e02e69..ef3dc2dd0 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -840,6 +840,12 @@ module = {
>enable = efi;
>  };
>
> +module = {
> +  name = efivar;
> +  efi = commands/efi/efivar.c;
> +  enable = efi;
> +};
> +
>  module = {
>name = blocklist;
>common = commands/blocklist.c;
> diff --git a/grub-core/commands/efi/efivar.c
> b/grub-core/commands/efi/efivar.c
> new file mode 100644
> index 0..8d81e01ab
> --- /dev/null
> +++ b/grub-core/commands/efi/efivar.c
> @@ -0,0 +1,150 @@
> +/* efivar.c - dump runtime uefi variables. */
> +/*
> + *  GRUB  --  GRand Unified Bootloader
> + *  Copyright (C) 2009  Free Software Foundation, Inc.
>
The date is wrong

>
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +GRUB_MOD_LICENSE ("GPLv3+");
> +
> +
> +/* Check if the data looks like UTF-16LE text */
> +static inline int
> +is_likely_utf16_string(grub_uint8_t *data, grub_size_t len)
> +{
> +if (len < 4) return 0;
> +for (grub_size_t i = 0; i < len; i += 2) {
> +if (data[i] == 0 && data[i+1] == 0) return 1; // Null terminator
> in UTF-16
> +if (data[i+1] != 0 && data[i+1] != 0x20) return 0; // High byte
> must be 0 or space-like
> +}
> +return 1;
> +}
>
This function is weird. What do you mean by space-like? Why null terminator
inside the string makes it "UTF-16 like"? An array 00 00 00 00 00 FF FF 00
is clearly non-UTF-16 yet this function returns 1

> +
> +static void
> +get_variable_data(const char *variable_name, grub_guid_t *variable_guid)
> +{
>
This is a dump function. Not a getter.

> +grub_efi_status_t status;
> +grub_efi_uint32_t attributes;
> +grub_size_t data_size;
> +grub_uint8_t *data;
> +
> +status = grub_efi_get_variable_with_attributes(variable_name,
> variable_guid,
> +   &data_size, (void
> **)&data, &attributes);
> +if (status != GRUB_EFI_SUCCESS)
> +{
> +grub_error(GRUB_ERR_BAD_MODULE,

Bad module is for bad grub modules. It's wrong error code

"Failed to retrieve variable data 0x%" PRIxGRUB_EFI_UINTN_T, status);
> +return;
> +}
> +
> +grub_printf("Attributes:\n");
>
Mark as translatable. Here and later.

> +if (attributes & GRUB_EFI_VARIABLE_NON_VOLATILE)
> +grub_printf("\tNon-Volatile\n");
> +if (attributes & GRUB_EFI_VARIABLE_BOOTSERVICE_ACCESS)
> +grub_printf("\tBoot Service Access\n");
> +if (attributes & GRUB_EFI_VARIABLE_RUNTIME_ACCESS)
> +grub_printf("\tRuntime Service Access\n");
> +
> +if (is_likely_utf16_string(data, data_size))
> +{
> +   grub_printf("Value (as UTF-16 string):\n");
> +   for (grub_size_t i = 0; i + 1 < data_size; i += 2)
> +   {
> +   grub_uint16_t ch = data[i] | (data[i+1] << 8);
> +   if (ch == 0) break;
> +   grub_printf("%c", (char)ch);  // crude but works if high
> byte is zero
>
We have a correct UTF-16 to UTF-8 converter.

> +   }
> +   grub_printf("\n");
> +}
> +else
> +{
> +   grub_printf("Value (hex):\n");
> +   for (grub_size_t i = 0; i < data_size; i++)
> +   {
> +   grub_printf("%02x ", data[i]);
>
We have a good hexdump function.

> +   if ((i + 1) % 16 == 0)
> +   grub_printf("\n");
> +   }
> +   grub_printf("\n");
> +}
> +
> +grub_free(data);
> +}
> +
> +static grub_err_t
> +dump_efi_variables(void)
> +{
> +   grub_efi_status_t status;
> +   grub_efi_runtime_services_t *r;
> +   grub_efi_uintn_t variable_name_size = 512;
> +   grub_efi_char16_t *variable_name;
> +   grub_uint8_t *variable_name_string = NULL;
> +   grub_guid_t vendor_guid;
> +
> +   r = grub_efi_system_table->runtime_services;
> +
> +   variable_name = grub_malloc(variable_name_size);
> +   if (!variable_name)
> +   return grub_error(GRUB_ERR_OUT_OF_MEMORY, "initial malloc
> failed");
>
Just return grub_errno.

> +   *variable_name = 0; /* Start with empty string */
> +
> +   while (1)
> +   {
> +   status = r->get_next_variable_name(&variable_name_size,
> variable_n

Re: [SECURITY PATCH 4/8] commands/search: Add the diskfilter support

[Vladimir 'phcoder' Serbinenko]

Le jeu. 8 mai 2025, 20:04, Daniel Kiper via Grub-devel 
a écrit :

> From: Maxim Suhanov 
>
> When the --cryptodisk-only argument is given, also check the target
> device using the "cryptocheck" command, if available.
>
> This extends the checks to common layouts like LVM-on-LUKS, so the
> --cryptodisk-only argument transparently handles such setups.
>
> Signed-off-by: Maxim Suhanov 
> Reviewed-by: Daniel Kiper 
> ---
>  grub-core/commands/search.c | 32 +++-
>  1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/commands/search.c b/grub-core/commands/search.c
> index f6bfef958..185c1e70f 100644
> --- a/grub-core/commands/search.c
> +++ b/grub-core/commands/search.c
> @@ -54,6 +54,36 @@ struct search_ctx
>int is_cache;
>  };
>
> +static bool
> +is_unencrypted_disk (grub_disk_t disk)
> +{
> +  grub_command_t cmd;
> +  char *disk_str;
> +  int disk_str_len;
> +  int res;
> +
> +  if (disk->dev->id == GRUB_DISK_DEVICE_CRYPTODISK_ID)
> +return false; /* This is (crypto) disk. */
> +
> +  if (disk->dev->id == GRUB_DISK_DEVICE_DISKFILTER_ID)
> +{
> +  cmd = grub_command_find ("cryptocheck");
>
I would prefer not to go through command parser but instead define a
function for crypto check.

+return true;
> +
> +  disk_str_len = grub_strlen (disk->name) + 2 + 1;
> +  disk_str = grub_malloc (disk_str_len);
> +  if (disk_str == NULL) /* Something is wrong, better report as
> unencrypted. */
>
You need to properly handle the error. Either reset grub_errno or to return
an error to upper layer (preferred).

> +return true;
> +
> +  grub_snprintf (disk_str, disk_str_len, "(%s)", disk->name);
> +  res = cmd->func (cmd, 1, &disk_str);
> +  grub_free (disk_str);
> +  return (res != GRUB_ERR_NONE) ? true : false; /* GRUB_ERR_NONE for
> encrypted. */
> +}
> +  return true;
> +}
> +
>  /* Helper for FUNC_NAME.  */
>  static int
>  iterate_device (const char *name, void *data)
> @@ -97,7 +127,7 @@ iterate_device (const char *name, void *data)
>   grub_errno = GRUB_ERR_NONE;
>   return 0;
> }
> -  if (dev->disk == NULL || dev->disk->dev->id !=
> GRUB_DISK_DEVICE_CRYPTODISK_ID)
> +  if (dev->disk == NULL || is_unencrypted_disk (dev->disk) == true)
> {
>   grub_device_close (dev);
>   grub_errno = GRUB_ERR_NONE;
> --
> 2.11.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

Re: [SECURITY PATCH 8/8] cryptocheck: Add --quiet option

[Vladimir 'phcoder' Serbinenko]

Can we use extcmd for this?


>
>
>if (disk->dev->id == GRUB_DISK_DEVICE_DISKFILTER_ID)
>  {
> +  char opt[] = "--quiet";
> +  char *args[2];
> +
>cmd = grub_command_find ("cryptocheck");
>if (cmd == NULL) /* No diskfilter module loaded for some reason. */
>  return true;
> @@ -77,7 +80,9 @@ is_unencrypted_disk (grub_disk_t disk)
>  return true;
>
>grub_snprintf (disk_str, disk_str_len, "(%s)", disk->name);
> -  res = cmd->func (cmd, 1, &disk_str);
> +  args[0] = opt;
> +  args[1] = disk_str;
> +  res = cmd->func (cmd, 2, args);
>grub_free (disk_str);
>return (res != GRUB_ERR_NONE) ? true : false; /* GRUB_ERR_NONE for
> encrypted. */
>  }
> diff --git a/grub-core/disk/diskfilter.c b/grub-core/disk/diskfilter.c
> index 9eda22e3f..3a26de60c 100644
> --- a/grub-core/disk/diskfilter.c
> +++ b/grub-core/disk/diskfilter.c
> @@ -1414,6 +1414,19 @@ grub_cmd_cryptocheck (grub_command_t cmd
> __attribute__ ((unused)),
>int check_pvs_res;
>int namelen;
>int pvs_cnt;
> +  int opt_quiet = 0;
> +
> +  if (argc == 2)
>
This needs extcmd for both consistency and better documentation.

> +{
> +  if (grub_strcmp (args[0], "--quiet") == 0)
> +   {
> + opt_quiet = 1;
> + argc--;
> + args++;
> +   }
> +  else
> +   return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("unrecognized option:
> %s"), args[0]);
> +}
>
>if (argc != 1)
>  return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("disk name expected"));
> @@ -1436,11 +1449,11 @@ grub_cmd_cryptocheck (grub_command_t cmd
> __attribute__ ((unused)),
>
>check_pvs_res = grub_diskfilter_check_pvs_encrypted (disk, &pvs_cnt);
>grub_disk_close (disk);
> -
> -  grub_printf("%s is %sencrypted (%d pv%s examined)\n", &args[0][1],
>
Please make this properly translatable. Use full sentences, ngettext and
avoid string arithmetic.

> -  (check_pvs_res == GRUB_ERR_NONE) ? "" : "un",
> -  pvs_cnt,
> -  (pvs_cnt > 1) ? "s" : "");
> +  if (!opt_quiet)
> +grub_printf ("%s is %sencrypted (%d pv%s examined)\n", &args[0][1],
> +(check_pvs_res == GRUB_ERR_NONE) ? "" : "un",
> +pvs_cnt,
> +(pvs_cnt > 1) ? "s" : "");
>

>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [SECURITY PATCH 3/8] disk/diskfilter: Introduce the "cryptocheck" command

[Vladimir 'phcoder' Serbinenko]

Le jeu. 8 mai 2025, 20:04, Daniel Kiper via Grub-devel 
a écrit :

> From: Maxim Suhanov 
>
> This command examines a given diskfilter device, e.g., an LVM disk,
> and checks if underlying disks, physical volumes, are cryptodisks,
> e.g., LUKS disks, this layout is called "LVM-on-LUKS".
>
> The return value is 0 when all underlying disks (of a given device)
> are cryptodisks (1 if at least one disk is unencrypted or in an
> unknown state).
>
> Users are encouraged to include the relevant check before loading
> anything from an LVM disk that is supposed to be encrypted.
>
> This further supports the CLI authentication, blocking bypass
> attempts when booting from an encrypted LVM disk.
>
> Signed-off-by: Maxim Suhanov 
> Reviewed-by: Daniel Kiper 
> ---
>  grub-core/disk/diskfilter.c | 75
> +
>  1 file changed, 75 insertions(+)
>
> diff --git a/grub-core/disk/diskfilter.c b/grub-core/disk/diskfilter.c
> index cc5062691..9eda22e3f 100644
> --- a/grub-core/disk/diskfilter.c
> +++ b/grub-core/disk/diskfilter.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1377,6 +1378,73 @@ grub_diskfilter_get_pv_from_disk (grub_disk_t disk,
>  }
>  #endif
>
> +static int
>
Please use bool if you want to return boolean or grub_err_t if you return
error codes. Int is undescriptive.

> +grub_diskfilter_check_pvs_encrypted (grub_disk_t disk, int *pvs_cnt)
> +{
> +  struct grub_diskfilter_lv *lv = disk->data;
> +  struct grub_diskfilter_pv *pv;
> +
> +  *pvs_cnt = 0;
> +
> +  if (lv->vg->pvs)
> +for (pv = lv->vg->pvs; pv; pv = pv->next)
> +  {
> +(*pvs_cnt)++;
> +
> +if (pv->disk == NULL)
> +  {
> +/* Can be a partially activated VG, bail out. */
> +return GRUB_ERR_TEST_FAILURE;
> +  }
> +
> +if (pv->disk->dev->id != GRUB_DISK_DEVICE_CRYPTODISK_ID)
> +  {
> +/* All backing devices must be cryptodisks, stop. */
> +return GRUB_ERR_TEST_FAILURE;
> +  }
> +  }
> +  return GRUB_ERR_NONE;
> +}
> +
> +static grub_err_t
> +grub_cmd_cryptocheck (grub_command_t cmd __attribute__ ((unused)),
> +   int argc, char **args)
> +{
> +  grub_disk_t disk;
> +  int check_pvs_res;
> +  int namelen;
> +  int pvs_cnt;
> +
> +  if (argc != 1)
> +return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("disk name expected"));
> +
> +  namelen = grub_strlen (args[0]);
> +  if (namelen > 2 && (args[0][0] == '(') && (args[0][namelen - 1] == ')'))
> +args[0][namelen - 1] = 0;
> +  else
> +return grub_error (GRUB_ERR_UNKNOWN_DEVICE, N_("invalid disk: %s"),
> +   args[0]);
> +
> +  if (!is_valid_diskfilter_name (&args[0][1]))
> +return grub_error (GRUB_ERR_UNKNOWN_DEVICE, N_("unrecognized disk:
> %s"),
> +   &args[0][1]);
> +
> +  disk = grub_disk_open (&args[0][1]);
> +  if (disk == NULL)
> +return grub_error (GRUB_ERR_UNKNOWN_DEVICE, N_("no such disk: %s"),
> +   &args[0][1]);
> +
> +  check_pvs_res = grub_diskfilter_check_pvs_encrypted (disk, &pvs_cnt);
> +  grub_disk_close (disk);
> +
> +  grub_printf("%s is %sencrypted (%d pv%s examined)\n", &args[0][1],
> +  (check_pvs_res == GRUB_ERR_NONE) ? "" : "un",
> +  pvs_cnt,
> +  (pvs_cnt > 1) ? "s" : "");
>
Please make this translatable

> +
> +  return check_pvs_res;
>
Please set grub_errno properly

> +}
> +
>  static struct grub_disk_dev grub_diskfilter_dev =
>{
>  .name = "diskfilter",
> @@ -1393,14 +1461,21 @@ static struct grub_disk_dev grub_diskfilter_dev =
>  .next = 0
>};
>
> +static grub_command_t cmd;
> +
>
>  GRUB_MOD_INIT(diskfilter)
>  {
>grub_disk_dev_register (&grub_diskfilter_dev);
> +  cmd = grub_register_command ("cryptocheck", grub_cmd_cryptocheck,
> +N_("DEVICE"),
> +N_("Check if a logical volume resides on
> encrypted disks."));
>  }
>
>  GRUB_MOD_FINI(diskfilter)
>  {
>grub_disk_dev_unregister (&grub_diskfilter_dev);
> +  if (cmd != NULL)
> +grub_unregister_command (cmd);
>free_array ();
>  }
> --
> 2.11.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

Re: [SECURITY PATCH 6/8] disk/cryptodisk: Add the "erase secrets" function

[Vladimir 'phcoder' Serbinenko]

Le jeu. 8 mai 2025, 20:04, Daniel Kiper via Grub-devel 
a écrit :

> From: Maxim Suhanov 
>
> This commit adds the grub_cryptodisk_erasesecrets() function to wipe
> master keys from all cryptodisks. This function is EFI-only.
>
> Since there is no easy way to "force unmount" a given encrypted disk,
> this function renders all mounted cryptodisks unusable. An attempt to
> read them will return garbage.
>
That is wrong. We need to unmount it and any further attempt to read from
given disk should return "no such disk".

>
> This is why this function must be used in "no way back" conditions.
>
> Currently, it is used when unloading the cryptodisk module and when
> performing the "exit" command (it is often used to switch to the next
> EFI application). This function is not called when performing the
> "chainloader" command, because the callee may return to GRUB. For this
> reason, users are encouraged to use "exit" instead of "chainloader" to
> execute third-party boot applications.
>
> This function does not guarantee that all secrets are wiped from RAM.
> Console output, chunks from disk read requests and other may remain.
>
> This function does not clear the IV prefix and rekey key for geli disks.
>
> Also, this commit adds the relevant documentation improvements.
>
> Signed-off-by: Maxim Suhanov 
> Reviewed-by: Daniel Kiper 
> ---
>  docs/grub.texi   |  6 ++
>  grub-core/commands/minicmd.c | 11 +++
>  grub-core/disk/cryptodisk.c  | 28 
>  include/grub/cryptodisk.h|  1 +
>  4 files changed, 46 insertions(+)
>
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 48438c2b6..cc4acb27e 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -6788,6 +6788,11 @@ namespace in addition to the cryptodisk namespace.
>
>  Support for plain encryption mode (plain dm-crypt) is provided via
> separate
>  @command{@pxref{plainmount}} command.
> +
> +On the EFI platform, GRUB tries to erase master keys from memory when the
> cryptodisk
> +module is unloaded or the command @command{exit} is executed. All secrets
> remain in
> +memory when the command @command{chainloader} is issued, because
> execution can
> +return to GRUB on the EFI platform.
>  @end deffn
>
>  @node cutmem
> @@ -9406,6 +9411,7 @@ USB support provides benefits similar to ATA (for
> USB disks) or AT (for USB
>  keyboards). In addition it allows USBserial.
>
>  Chainloading refers to the ability to load another bootloader through the
> same protocol
> +and on some platforms, like EFI, allow that bootloader to return to the
> GRUB.
>
>  Hints allow faster disk discovery by already knowing in advance which is
> the disk in
>  question. On some platforms hints are correct unless you move the disk
> between boots.
> diff --git a/grub-core/commands/minicmd.c b/grub-core/commands/minicmd.c
> index 8c5ee3e60..ff4ff021c 100644
> --- a/grub-core/commands/minicmd.c
> +++ b/grub-core/commands/minicmd.c
> @@ -29,6 +29,10 @@
>  #include 
>  #include 
>
> +#ifdef GRUB_MACHINE_EFI
> +#include 
> +#endif
> +
>  GRUB_MOD_LICENSE ("GPLv3+");
>
>  /* cat FILE */
> @@ -187,6 +191,13 @@ grub_mini_cmd_exit (struct grub_command *cmd
> __attribute__ ((unused)),
> int argc __attribute__ ((unused)),
> char *argv[] __attribute__ ((unused)))
>  {
> +#ifdef GRUB_MACHINE_EFI
> +  /*
> +   * The "exit" command is often used to launch the next boot application.
> +   * So, erase the secrets.
> +   */
> +  grub_cryptodisk_erasesecrets ();
> +#endif
>grub_exit ();
>/* Not reached.  */
>  }
> diff --git a/grub-core/disk/cryptodisk.c b/grub-core/disk/cryptodisk.c
> index 7a785a49c..544a30d61 100644
> --- a/grub-core/disk/cryptodisk.c
> +++ b/grub-core/disk/cryptodisk.c
> @@ -1856,6 +1856,31 @@ grub_cryptodisk_challenge_password (void)
>
>return GRUB_ERR_NONE;
>  }
> +
> +void
> +grub_cryptodisk_erasesecrets (void)
> +{
> +  grub_cryptodisk_t i;
> +  grub_uint8_t *buf;
> +
> +  buf = grub_zalloc (GRUB_CRYPTODISK_MAX_KEYLEN);
> +  if (buf == NULL)
> +grub_fatal ("grub_cryptodisk_erasesecrets: cannot allocate memory");
> +
> +  for (i = cryptodisk_list; i != NULL; i = i->next)
> +if (grub_cryptodisk_setkey (i, buf, i->keysize))
> +  grub_fatal ("grub_cryptodisk_erasesecrets: cannot erase secrets for
> %s", i->source);
> +else
> +  grub_printf ("Erased crypto secrets for %s\n", i->source);
> +  /*
> +   * Unfortunately, there is no way to "force unmount" a given disk,
> it may
> +   * have mounted "child" disks as well, e.g., an LVM volume. So, this
> +   * function MUST be called when there is no way back, e.g., when
> exiting.
> +   * Otherwise, subsequent read calls for a cryptodisk will return
> garbage.
> +   */
> +
> +  grub_free (buf);
> +}
>  #endif /* GRUB_MACHINE_EFI */
>
>  struct grub_procfs_entry luks_script =
> @@ -1880,6 +1905,9 @@ GRUB_MOD_INIT (cryptodisk)
>
>  GRUB_MOD_FINI (cryptodisk)
>  {
> +#ifdef GRUB_MACHINE_EFI
> +  gr

Re: [SECURITY PATCH 7/8] disk/cryptodisk: Wipe the passphrase from memory

[Vladimir 'phcoder' Serbinenko]

Reviewed-by: Vladimir Serbinenko phco...@gmail.com

Regards
Vladimir 'phcoder' Serbinenko

Le jeu. 8 mai 2025, 20:04, Daniel Kiper via Grub-devel 
a écrit :

> From: Maxim Suhanov 
>
> Switching to another EFI boot application while there are secrets in
> RAM is dangerous, because not all firmware is wiping memory on free.
>
> To reduce the attack surface, wipe the passphrase acquired when
> unlocking an encrypted volume.
>
> Signed-off-by: Maxim Suhanov 
> Reviewed-by: Daniel Kiper 
> ---
>  grub-core/disk/cryptodisk.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/grub-core/disk/cryptodisk.c b/grub-core/disk/cryptodisk.c
> index 544a30d61..7065bcdcb 100644
> --- a/grub-core/disk/cryptodisk.c
> +++ b/grub-core/disk/cryptodisk.c
> @@ -1302,6 +1302,7 @@ grub_cryptodisk_scan_device_real (const char *name,
>
>if (askpass)
>  {
> +  grub_memset (cargs->key_data, 0, cargs->key_len);
>cargs->key_len = 0;
>grub_free (cargs->key_data);
>  }
> --
> 2.11.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

Re: [PATCH v2 0/1] loader/efi/chainloader: Enhance error message of chainloader

[Vladimir 'phcoder' Serbinenko]

I believe haphazard ad-hoc approach is not a way to go. I see 2 valid
approaches:
* Have a central EFI to grub error converter that would print error code
and message
* Just print EFI error code in hex and tell that only experts are
interested in those details

Regards
Vladimir 'phcoder' Serbinenko

Le mer. 7 mai 2025, 19:22, khaliid caliy  a écrit :

> This patch addresses some undescriptive error messages that grub
> chainloader command returns when issue encountered, specifically
> during the loading of the uefi image or starting the image.
>
> As per uefi UEFI specification (2.11) boot service functions
> `StartImage()` and `LoadImage` return error codes that describe the
> issue happened, which the command didn't check and suppressed it. The
> current implementation of the command prints some generic error
> messages like "unknown error", "cannot load image". Which doesn't tell
> much of the nature of the issue and what happened.
>
> So my patch addresses the command error message and prints the error
> based on the return value of the functions or else prints the status
> code returned by the functions.
>
> diff --git a/grub-core/loader/efi/chainloader.c
> b/grub-core/loader/efi/chainloader.c
> index 869307bf3..c0ef37489 100644
> --- a/grub-core/loader/efi/chainloader.c
> +++ b/grub-core/loader/efi/chainloader.c
> @@ -91,7 +91,7 @@ grub_chainloader_boot (void *context)
>}
>}
>   else
> -   grub_error (GRUB_ERR_BAD_OS, "unknown error");
> +   grub_error (GRUB_ERR_BAD_OS, "cannot start image 0x%"
> PRIxGRUB_EFI_UINTN_T, status);
> }
>
>   if (exit_data)
> @@ -346,8 +346,12 @@ grub_cmd_chainloader (grub_command_t cmd
> __attribute__ ((unused)),
> {
>   if (status == GRUB_EFI_OUT_OF_RESOURCES)
>grub_error (GRUB_ERR_OUT_OF_MEMORY, "out of resources");
> +  else if (status == GRUB_EFI_UNSUPPORTED)
> +   grub_error(GRUB_ERR_BAD_OS, "image is not supported");
> +  else if (status == GRUB_EFI_INVALID_PARAMETER)
> +   grub_error(GRUB_ERR_BAD_ARGUMENT, "invalid argument");
>   else
> -   grub_error (GRUB_ERR_BAD_OS, "cannot load image");
> +   grub_error (GRUB_ERR_BAD_OS, "cannot load image 0x%"
> PRIxGRUB_EFI_UINTN_T, status);
>
>   goto fail;
> }
>
> Checking error messages is important and may save time for users or
> professionals. So please let me know for any improvement, adjustment
> or any other feedback.
>
> Thanks best regards khaalid
>
> ___
> 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] testpci: initial module

[Vladimir 'phcoder' Serbinenko]

 spaces */
> +p = buf;
> +while (*p && grub_isspace(*p)) {
> +  p++;
> +}
> +
> +/* ignore empty */
> +if (*p == '\0')
> +  continue;
> +
> +testpci_add_device_to_list(&devlist, p);
> +if (!(devlist.devices)) {
> +  return GRUB_ERR_OUT_OF_MEMORY;
>
Ditto

> +}
> +
> +  }
> +
> +  grub_file_close (listfile);
> +}
> +  }
> +
> +  for (int d = 0 ; d < devlist.n_devices; d++) {
> +if (grub_strlen(devlist.devices[d]) != 9 || devlist.devices[d][4] !=
> ':') {
> +  grub_printf("bad input device (%d) \"%s\", expected :\n",
> d, devlist.devices[d]);
>
Return an error.

> +}
> +  }
> +
> +  grub_pci_iterate (grub_testpci_iter, (void*)&devlist);
> +
> +  for (int i = 0; i < devlist.n_devices; i++) {
> +grub_free(devlist.devices[i]);
> +  }
> +  grub_free(devlist.devices);
> +  return devlist.found ? GRUB_ERR_NONE : GRUB_ERR_TEST_FAILURE;
>
You need to call grub_error here

> +}
> +
> +static grub_extcmd_t cmd;
> +
> +GRUB_MOD_INIT(testpci)
> +{
> +  cmd = grub_register_extcmd ("testpci", grub_cmd_testpci, 0,
> +  "[ [...]] [--file ]",
> +  N_("Check if any of the PCI devices
> exist."), options);
> +}
> +
> +GRUB_MOD_FINI(testpci)
> +{
> +  grub_unregister_extcmd (cmd);
> +}
> --
> 2.39.5
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Testing for specific PCI devices

[Vladimir 'phcoder' Serbinenko]

Patches should be in logical chunks. In your case squashing is the way to go

Regards
Vladimir 'phcoder' Serbinenko

Le mar. 6 mai 2025, 17:36, Yair Yarom  a écrit :

>
> I've made the changes, but I'm inexperienced with git send or the policy
> here. Should I send the patches as is (several commits for the fixes
> above), or should I squash it, or commit per file, etc.
>
> Thanks,
>
> On Sat, 3 May 2025 at 17:01, Vladimir 'phcoder' Serbinenko <
> phco...@gmail.com> wrote:
>
>> Generally looks ok but there are few comments like using err_t as a
>> boolean with inverted semantics is unintuitive. Check for grub_malloc
>> return value is completely missing. Goto is discouraged.
>> Can you send using git send to the ML so it can be reviewed properly?
>>
>> Le jeu. 24 avr. 2025, 15:44, Yair Yarom  a écrit :
>>
>>> Hi,
>>>
>>> Sure, I've uploaded my changes to github:
>>> https://github.com/irush-cs/grub/tree/irush/testpci
>>>
>>> Generally, this is a 'testpci' command that accepts one or more PCI
>>> device IDs in the form ":" as arguments, or reads lines from a file
>>> given by the --file parameter, and returns true if one or more of those PCI
>>> devices is present, and false otherwise.
>>>
>>> Thanks,
>>> Yair.
>>>
>>>
>>>
>>> On Wed, 23 Apr 2025 at 18:13, Vladimir 'phcoder' Serbinenko <
>>> phco...@gmail.com> wrote:
>>>
>>>> Hello. Such a functionality would be beneficial for GRUB. For more
>>>> details I'd have to see at least the proposed interface if not the actual
>>>> patches
>>>>
>>>> Regards
>>>> Vladimir 'phcoder' Serbinenko
>>>>
>>>> Le mer. 23 avr. 2025, 11:56, Yair Yarom  a écrit :
>>>>
>>>>> Hi,
>>>>>
>>>>> We have a netboot environment, and for some machines we need to add
>>>>> different kernel parameters (or different initrd) according to specific
>>>>> devices - usually network devices, iommu, etc. things that cannot be tuned
>>>>> after the kernel is up.
>>>>>
>>>>> For this we developed a 'testpci' grub command that can be used as an
>>>>> 'if' condition test. Is this of any interest to the community? I'm not 
>>>>> sure
>>>>> what's the proper method for sending such ideas/patches.
>>>>>
>>>>> Regards,
>>>>> Yair.
>>>>>
>>>>>
>>>>> ___
>>>>> 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
>>>>
>>>
>>> ___
>>> 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
>>
> ___
> 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: Testing for specific PCI devices

[Vladimir 'phcoder' Serbinenko]

Generally looks ok but there are few comments like using err_t as a boolean
with inverted semantics is unintuitive. Check for grub_malloc return value
is completely missing. Goto is discouraged.
Can you send using git send to the ML so it can be reviewed properly?

Le jeu. 24 avr. 2025, 15:44, Yair Yarom  a écrit :

> Hi,
>
> Sure, I've uploaded my changes to github:
> https://github.com/irush-cs/grub/tree/irush/testpci
>
> Generally, this is a 'testpci' command that accepts one or more PCI device
> IDs in the form ":" as arguments, or reads lines from a file given
> by the --file parameter, and returns true if one or more of those PCI
> devices is present, and false otherwise.
>
> Thanks,
> Yair.
>
>
>
> On Wed, 23 Apr 2025 at 18:13, Vladimir 'phcoder' Serbinenko <
> phco...@gmail.com> wrote:
>
>> Hello. Such a functionality would be beneficial for GRUB. For more
>> details I'd have to see at least the proposed interface if not the actual
>> patches
>>
>> Regards
>> Vladimir 'phcoder' Serbinenko
>>
>> Le mer. 23 avr. 2025, 11:56, Yair Yarom  a écrit :
>>
>>> Hi,
>>>
>>> We have a netboot environment, and for some machines we need to add
>>> different kernel parameters (or different initrd) according to specific
>>> devices - usually network devices, iommu, etc. things that cannot be tuned
>>> after the kernel is up.
>>>
>>> For this we developed a 'testpci' grub command that can be used as an
>>> 'if' condition test. Is this of any interest to the community? I'm not sure
>>> what's the proper method for sending such ideas/patches.
>>>
>>> Regards,
>>> Yair.
>>>
>>>
>>> ___
>>> 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
>>
>
> ___
> 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 0/3] Use -shared compilation instead of -Wl,-r

[Vladimir 'phcoder' Serbinenko]

Thanks. Fixed in the new version

Regards
Vladimir 'phcoder' Serbinenko

Le jeu. 24 avr. 2025, 18:43, Mate Kukri  a écrit :

> ia32-efi build breaks with these patches, grub-mkimage seems to be
> missing relocation type 8
>
> On Tue, Apr 8, 2025 at 4:16 PM Vladimir Serbinenko 
> wrote:
> >
> > -Wl,-r is a partial linking and this file is only intended as
> intermediate
> > result for linker, not really intended for any other use. To make them
> > usable we end up doing all the linker job twice over: in mkimage and
> > in runtime. -shared on the other hand is meant to be loaded and relocated
> > and hence it's simpler to use.
> >
> > Tested on
> > i386-pc, x86_64-efi, powerpc-ieee1275, arm-efi, riscv64-efi,
> > arm64-efi, sparc64-ieee1275, mipsel-loongson, mips-malta and
> > loongarch64-efi using qemu
> >
> > Tested on ia64-efi using ski
> > Tested on emu
> >
> > Couldn't test on riscv32 as I couldn't find riscv32-efi for qemu, or any
> > board for this matter.
> >
> >
> > ___
> > 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
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 1/2] Include function name on debug traces

[Vladimir 'phcoder' Serbinenko]

Le mer. 23 avr. 2025, 01:39, Leo Sandoval  a écrit :

>
>
> On Tue, Apr 15, 2025 at 9:28 AM Vladimir 'phcoder' Serbinenko <
> phco...@gmail.com> wrote:
>
>> What is the code size increase on i386-pc? Did you test it? This is
>> likely to result in a big one
>>
>
> I did not test the binary size impact but  du'ing does not show
> much degradation (around 24kb increase) on my fedora box
>

The size of modules is mostly irrelevant. What matters are the core sizes.
./grub-mkimage -O i386-pc -p /boot/grub -o core.img biosdisk part_msdos
ext2
Resulting core has to be under 31K for all the filesystems (replace ext2
with different FS) except btrfs and zfs

>
> before patch
>
> # du  /boot/grub2/
> 3404 /boot/grub2/i386-pc
> 5484 /boot/grub2/locale
> 2344 /boot/grub2/fonts
> 11252 /boot/grub2/
>
> with patch
>
> # du  /boot/grub2/
> 3428 /boot/grub2/i386-pc
> 5484 /boot/grub2/locale
> 2344 /boot/grub2/fonts
> 11276 /boot/grub2/
>
>
>
>
>>
>> Regards
>> Vladimir 'phcoder' Serbinenko
>>
>> Le sam. 12 avr. 2025, 01:03, Leo Sandoval via Grub-devel <
>> grub-devel@gnu.org> a écrit :
>>
>>> Together with the line number, the debug trace with the function name
>>> provides a bit more context and could be useful when inspecting log.
>>>
>>> Signed-off-by: Leo Sandoval 
>>> ---
>>>  grub-core/kern/misc.c | 4 ++--
>>>  include/grub/misc.h   | 5 +++--
>>>  2 files changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/grub-core/kern/misc.c b/grub-core/kern/misc.c
>>> index 2b79223935..90c71d7cea 100644
>>> --- a/grub-core/kern/misc.c
>>> +++ b/grub-core/kern/misc.c
>>> @@ -231,14 +231,14 @@ grub_debug_enabled (const char * condition)
>>>  }
>>>
>>>  void
>>> -grub_real_dprintf (const char *file, const int line, const char
>>> *condition,
>>> +grub_real_dprintf (const char *file, const char *function, const int
>>> line, const char *condition,
>>>const char *fmt, ...)
>>>  {
>>>va_list args;
>>>
>>>if (grub_debug_enabled (condition))
>>>  {
>>> -  grub_printf ("%s:%d:%s: ", file, line, condition);
>>> +  grub_printf ("%s:%s:%d:%s: ", file, function, line, condition);
>>>va_start (args, fmt);
>>>grub_vprintf (fmt, args);
>>>va_end (args);
>>> diff --git a/include/grub/misc.h b/include/grub/misc.h
>>> index e087e7b3e8..881af5ca98 100644
>>> --- a/include/grub/misc.h
>>> +++ b/include/grub/misc.h
>>> @@ -35,7 +35,7 @@
>>>  #define ARRAY_SIZE(array) (sizeof (array) / sizeof (array[0]))
>>>  #define COMPILE_TIME_ASSERT(cond) switch (0) { case 1: case !(cond): ; }
>>>
>>> -#define grub_dprintf(condition, ...) grub_real_dprintf(GRUB_FILE,
>>> __LINE__, condition, __VA_ARGS__)
>>> +#define grub_dprintf(condition, ...) grub_real_dprintf(GRUB_FILE,
>>> __FUNCTION__, __LINE__, condition, __VA_ARGS__)
>>>
>>>  void *EXPORT_FUNC(grub_memmove) (void *dest, const void *src,
>>> grub_size_t n);
>>>  char *EXPORT_FUNC(grub_strcpy) (char *dest, const char *src);
>>> @@ -410,9 +410,10 @@ grub_puts (const char *s)
>>>  int EXPORT_FUNC(grub_puts_) (const char *s);
>>>  int EXPORT_FUNC(grub_debug_enabled) (const char *condition);
>>>  void EXPORT_FUNC(grub_real_dprintf) (const char *file,
>>> + const int function,
>>>   const int line,
>>>   const char *condition,
>>> - const char *fmt, ...)
>>> __attribute__ ((format (GNU_PRINTF, 4, 5)));
>>> + const char *fmt, ...)
>>> __attribute__ ((format (GNU_PRINTF, 5, 6)));
>>>  int EXPORT_FUNC(grub_printf) (const char *fmt, ...) __attribute__
>>> ((format (GNU_PRINTF, 1, 2)));
>>>  int EXPORT_FUNC(grub_printf_) (const char *fmt, ...) __attribute__
>>> ((format (GNU_PRINTF, 1, 2)));
>>>  int EXPORT_FUNC(grub_vprintf) (const char *fmt, va_list args);
>>> --
>>> 2.48.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: Testing for specific PCI devices

[Vladimir 'phcoder' Serbinenko]

Hello. Such a functionality would be beneficial for GRUB. For more details
I'd have to see at least the proposed interface if not the actual patches

Regards
Vladimir 'phcoder' Serbinenko

Le mer. 23 avr. 2025, 11:56, Yair Yarom  a écrit :

> Hi,
>
> We have a netboot environment, and for some machines we need to add
> different kernel parameters (or different initrd) according to specific
> devices - usually network devices, iommu, etc. things that cannot be tuned
> after the kernel is up.
>
> For this we developed a 'testpci' grub command that can be used as an 'if'
> condition test. Is this of any interest to the community? I'm not sure
> what's the proper method for sending such ideas/patches.
>
> Regards,
> Yair.
>
>
> ___
> 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 2/2] kern/efi/mm: ask for more that 4GB if we need it

[Vladimir 'phcoder' Serbinenko]

Above 4 GiB is never suitable for 32-bit platforms. 64-bit platforms need
tests and/or analysis. I prefer increasing max address rather than having a
fallback to any_pages. In parallel threads there is already a discussion of
memory allocations on riscv64 and aarch64.

The summary:
i386_efi, arm_efi, riscv32_efi: max address is set to 4GiB-1 and can't be
increased. Any pages is not suitable.
x86_64_efi: currently either 2GiB-1 or 4GiB-1. To increase it we need to
both force mcmodel=large and solve mapping problem
ia64_efi: currently set at 4GiB-1. Probably can be increased
arm64_efi: currently at 256TiB-1. Without D128 it's the highest mappable
address on arm64. There is a report that this value causes problem on some
Lenovo systems.
riscv64_efi: value is the same as arm64. I didn't check how MMU works on
riscv64 so can't say if this matches the real limitation or just a
copy-paste mistake. In either case this value already causes some problems
and we need to force mcmodel=large first.
loongarch64_efi: 16TiB-1. No idea why. No complaints for it either.

In an ideal world we should use any_pages on all 64-bit systems but as you
can see compiler aspects, MMU limits and firmware bugs limit its usefulness

Regards

Le mar. 22 avr. 2025, 23:34, Paymon MARANDI  a
écrit :

> earlier version of this didn't count for other archs and actually
> mapping the unmapped memory above 4GB.
>
> this builds on top of the previous patch (by phcoder) in the series and
> hopefully will do all of the above.
>
> Signed-off-by: Paymon MARANDI 
> ---
>  grub-core/kern/efi/mm.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
> index 60ac7ed00..34615826d 100644
> --- a/grub-core/kern/efi/mm.c
> +++ b/grub-core/kern/efi/mm.c
> @@ -178,9 +178,18 @@ grub_efi_allocate_pages_real
> (grub_efi_physical_address_t address,
>  void *
>  grub_efi_allocate_any_pages (grub_efi_uintn_t pages)
>  {
> -  return grub_efi_allocate_pages_real (GRUB_EFI_MAX_USABLE_ADDRESS,
> -  pages,
> GRUB_EFI_ALLOCATE_MAX_ADDRESS,
> -  GRUB_EFI_LOADER_DATA);
> +  void *ret;
> +  ret = grub_efi_allocate_pages_real (GRUB_EFI_MAX_USABLE_ADDRESS, pages,
> +  GRUB_EFI_ALLOCATE_MAX_ADDRESS,
> +  GRUB_EFI_LOADER_DATA);
> +  if (ret == NULL)
> +{
> +  grub_errno = GRUB_ERR_NONE;
> +  ret = grub_efi_allocate_pages_real (GRUB_EFI_MAX_USABLE_ADDRESS,
> + pages,
> GRUB_EFI_ALLOCATE_ANY_PAGES,
> + GRUB_EFI_LOADER_DATA);
> +}
> +  return ret;
>  }
>
>  void *
> --
> 2.49.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

Re: [PATCH 1/2] x86_64-efi: Ensure that memory is mapped when allocating

[Vladimir 'phcoder' Serbinenko]

This will need fixes. I already have a newer version. Real problem though
is testing it

Regards
Vladimir 'phcoder' Serbinenko

Le mar. 22 avr. 2025, 23:33, Paymon MARANDI  a
écrit :

> From: Vladimir Serbinenko 
>
> This is a replacement workaround for EFIs that do not map memory above 4G
> and allows to increase maximum available address to 128TiB
> ---
>  grub-core/Makefile.core.def|  1 +
>  grub-core/kern/efi/mm.c| 10 
>  grub-core/kern/x86_64/efi/mm.c | 84 ++
>  include/grub/efi/memory.h  |  5 ++
>  4 files changed, 100 insertions(+)
>  create mode 100644 grub-core/kern/x86_64/efi/mm.c
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index 7f8cb3f7d..57e76dda5 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -219,6 +219,7 @@ kernel = {
>efi = kern/efi/acpi.c;
>efi = kern/efi/sb.c;
>efi = kern/lockdown.c;
> +  x86_64_efi = kern/x86_64/efi/mm.c;
>i386_coreboot = kern/i386/pc/acpi.c;
>i386_multiboot = kern/i386/pc/acpi.c;
>i386_coreboot = kern/acpi.c;
> diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
> index df238b165..60ac7ed00 100644
> --- a/grub-core/kern/efi/mm.c
> +++ b/grub-core/kern/efi/mm.c
> @@ -160,6 +160,16 @@ grub_efi_allocate_pages_real
> (grub_efi_physical_address_t address,
> }
>  }
>
> +#ifdef __x86_64__
> +  status = grub_efi_arch_ensure_mapping (address, pages);
> +  if (status != GRUB_EFI_SUCCESS)
> +{
> +  b->free_pages (address, pages);
> +  grub_error (GRUB_ERR_OUT_OF_MEMORY, N_("out of memory"));
> +  return NULL;
> +}
> +#endif
> +
>grub_efi_store_alloc (address, pages);
>
>return (void *) ((grub_addr_t) address);
> diff --git a/grub-core/kern/x86_64/efi/mm.c
> b/grub-core/kern/x86_64/efi/mm.c
> new file mode 100644
> index 0..01e2b9ac4
> --- /dev/null
> +++ b/grub-core/kern/x86_64/efi/mm.c
> @@ -0,0 +1,84 @@
> +/*
> + *  GRUB  --  GRand Unified Bootloader
> + *  Copyright (C) 2025  Free Software Foundation, Inc.
> + *
> + *  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 <http://www.gnu.org/licenses/>.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static grub_efi_status_t
> +create_paging_entry(grub_uint64_t *entry)
> +{
> +  grub_efi_status_t status;
> +  grub_efi_boot_services_t *b;
> +
> +  grub_uint64_t address = 0x;
> +
> +  b = grub_efi_system_table->boot_services;
> +  /* TODO: Which type should it be?  */
> +  status = b->allocate_pages (GRUB_EFI_ALLOCATE_MAX_ADDRESS,
> GRUB_EFI_LOADER_DATA, 1, &address);
> +  if (status != GRUB_EFI_SUCCESS)
> +return status;
> +  *entry = address | 7;
> +  return GRUB_EFI_SUCCESS;
> +}
> +
> +grub_efi_status_t
> +grub_efi_arch_ensure_mapping (grub_efi_physical_address_t address,
> + grub_efi_uintn_t pages)
> +{
> +  grub_uint64_t cr3;
> +  asm volatile("movq   %%cr3, %0\n" : "=r"(cr3));
> +  for (grub_uint64_t page = 0; page < pages; page++)
> +{
> +  grub_uint64_t pageidx = (address >> 12) + page;
> +  grub_uint64_t *pt4 = (grub_uint64_t *) cr3;
> +  if (!(pt4[pageidx >> 27] & 1)) {
> +   grub_efi_status_t status = create_paging_entry(&pt4[pageidx >>
> 27]);
> +   if (status != GRUB_EFI_SUCCESS)
> + return status;
> +  }
> +  grub_uint64_t *pt3 = (grub_uint64_t *) (pt4[pageidx >> 27] &
> ~0xfff);
> +  if (!(pt3[pageidx >> 18] & 1)) {
> +   grub_efi_status_t status = create_paging_entry(&pt3[pageidx >>
> 18]);
> +   if (status != GRUB_EFI_SUCCESS)
> + return status;
> +  }
> +  if (pt3[pageidx >> 18] & 0x80)
> +   continue;
> +  grub_uint64_t *pt2 = (grub_uint64_t *) (pt3[pageidx >> 18] &
> ~0xfff);
> +  if (!(pt2[pageidx >> 9] & 1)) {
> +   gr

Re: [PATCH 0/2] kern/efi/mm.c: add range check on risc-v

[Vladimir 'phcoder' Serbinenko]

Le mar. 22 avr. 2025, 07:26, Adriano Cordova Fedeli <
adriano.cord...@canonical.com> a écrit :

> The series '[PATCH 0/3] Use -shared compilation instead of -Wl,-r' seems
> to fix the relocation error and grub loads fine when mcmodel=large. But
> still not sure what happens if mcmodel=medany and we allocate something
> more than 2GiB away, probably relocation overflow.
>
Is there any problem with making mcmodel large mandatory on riscv?

>
> On Mon, 21 Apr 2025 at 20:03, Vladimir 'phcoder' Serbinenko <
> phco...@gmail.com> wrote:
>
>>
>>
>> Le mar. 22 avr. 2025, 01:13, Adriano Cordova Fedeli <
>> adriano.cord...@canonical.com> a écrit :
>>
>>> Hi Vladimir,
>>>
>>> I just subscribed to the mailing list. Copying your 1/3 patch by hand
>>> says it is corrupted. Do you have a git branch with that series for me to
>>> test, or the .patch files?
>>>
>> Pushed as https://github.com/phcoder/GRUB/tree/mshared
>> ___
>> 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
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 0/2] kern/efi/mm.c: add range check on risc-v

[Vladimir 'phcoder' Serbinenko]

Le mar. 22 avr. 2025, 01:13, Adriano Cordova Fedeli <
adriano.cord...@canonical.com> a écrit :

> Hi Vladimir,
>
> I just subscribed to the mailing list. Copying your 1/3 patch by hand says
> it is corrupted. Do you have a git branch with that series for me to test,
> or the .patch files?
>
Pushed as https://github.com/phcoder/GRUB/tree/mshared
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 0/2] kern/efi/mm.c: add range check on risc-v

[Vladimir 'phcoder' Serbinenko]

I believe the problem you describe is fixed by series of patches '[PATCH
0/3] Use -shared compilation instead of -Wl,-r'. Can you try them?

Regards
Vladimir 'phcoder' Serbinenko

Le lun. 21 avr. 2025, 18:56, Adriano Cordova  a écrit :

> The current grub risc-v ELF loader does not support some of the
> relocations produced by -mcmodel=large (e.g. when compiled with
> -mcmodel=large grub-mkimage returns 'error: relocation 0x2b is
> not implemented yet.'), so it has to be compiled with
> -mcmodel=medany, which only works if the grub code fits in 2GiB.
> The following patches add a range check to the grub EFI memory
> allocator to ensure this.
>
> Adriano Cordova (2):
>   kern/efi/mm.c: Add optional range check
>   kern/efi/mm.c: use GRUB_MM_ADD_REGION_IN_RANGE on risc-v
>
>  grub-core/kern/efi/mm.c | 60 ++---
>  include/grub/mm.h   |  1 +
>  2 files changed, 57 insertions(+), 4 deletions(-)
>
> --
> 2.48.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 v3 1/3] blsuki: Add blscfg command to parse Boot Loader Specification snippets

[Vladimir 'phcoder' Serbinenko]

> > +module = {
> > +  name = blsuki;
> > +  common = commands/blsuki.c;
> > +  common = lib/vercmp.c;
>
> Probably this should be a part of the kernel.
>
> > +  enable = powerpc_ieee1275;
>
> ??? Really? PowerPC? IEEE 1275? I think something is off here...
>
BLS is specified for ieee1275 explicitly. And the spec actually works for
all platforms. We should website or on all the platforms. As for UKI, it's
compatible with EFI through chainloader and potentially compatible with
others through image parsing.
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] kern/efi/mm: try allocating in the lower 4GB first

[Vladimir 'phcoder' Serbinenko]

Can you run lsefimmap and lspaging on the system in question? lspaging
patch is in neighboring thread

Regards
Vladimir 'phcoder' Serbinenko

Le ven. 11 avr. 2025, 14:01, Vladimir 'phcoder' Serbinenko <
phco...@gmail.com> a écrit :

> How early is this bug? Do you see "Welcome to GRUB"? Does recompiling with
> fPIC help? Do you have memory map dump and paging table dump?
>
> Regards
> Vladimir 'phcoder' Serbinenko
>
> Le ven. 11 avr. 2025, 13:39, Tobias Heider 
> a écrit :
>
>> On arm64 we can't restrict memory usage below 0x as we do
>> on x86 because there is no guarantee memory in that range exists
>> at all (an example is Apple Silicon).
>> Instead, try to allocate in the lower 4GB range first and fall
>> back to the entire available address space if that did not work.
>>
>> This fixes a bug on Snapdragon X Elite devices such as the Lenovo
>> Thinkpad T14s which crashes when accessing memory above 0x.
>>
>> Signed-off-by: Tobias Heider 
>> ---
>>
>>  For previous discussion see
>>  https://lists.gnu.org/archive/html/grub-devel/2025-04/msg00072.html
>>
>>  In contrast to the previous patch this one affects all archs.
>>  It seems generally safe not to limit it to arm64 with the fallback
>>  to the old behaviour but I'd be interested to hear if there are any
>>  concerns.
>>  Tested on a Snapdragon X Elite and Macbook M2 Air.
>>
>>  grub-core/kern/efi/mm.c | 16 +---
>>  1 file changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
>> index df238b165..029d975dd 100644
>> --- a/grub-core/kern/efi/mm.c
>> +++ b/grub-core/kern/efi/mm.c
>> @@ -168,9 +168,19 @@ grub_efi_allocate_pages_real
>> (grub_efi_physical_address_t address,
>>  void *
>>  grub_efi_allocate_any_pages (grub_efi_uintn_t pages)
>>  {
>> -  return grub_efi_allocate_pages_real (GRUB_EFI_MAX_USABLE_ADDRESS,
>> -  pages,
>> GRUB_EFI_ALLOCATE_MAX_ADDRESS,
>> -  GRUB_EFI_LOADER_DATA);
>> +  void *ret;
>> +
>> +  ret = grub_efi_allocate_pages_real (0x,
>> + pages,
>> GRUB_EFI_ALLOCATE_MAX_ADDRESS,
>> + GRUB_EFI_LOADER_DATA);
>> +  if (ret == NULL)
>> +{
>> +  grub_errno = GRUB_ERR_NONE;
>> +  ret = grub_efi_allocate_pages_real (GRUB_EFI_MAX_USABLE_ADDRESS,
>> + pages,
>> GRUB_EFI_ALLOCATE_MAX_ADDRESS,
>> + GRUB_EFI_LOADER_DATA);
>> +}
>> +  return ret;
>>  }
>>
>>  void *
>> --
>> 2.48.1
>>
>>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 3/3] blsuki: Add uki command to load Unified Kernel Image entries

[Vladimir 'phcoder' Serbinenko]

Le sam. 12 avr. 2025, 06:45, Alec Brown  a écrit :

> On Tue, Apr 1, 2025 at 6:35 AM, Vladimir 'phcoder' Serbinenko <
> phco...@gmail.com> wrote:
> > Le jeu. 27 mars 2025, 23:44, Alec Brown  a
> écrit :
> >
> >> On Wed, Mar 26, 2025 at 5:43 AM, Vladimir 'phcoder' Serbinenko <
> >> phco...@gmail.com> wrote:
> >> >>
> >> >>
> >> >>
> >> >> +#ifdef GRUB_MACHINE_EFI
> >> >> +#include 
> >> >> +#include 
> >> >> +#include 
> >> >> +#endif
> >> >> +
> >> >>
> >> > Can UKI work without EFI? I think of scenario of putting e.g. EFI disk
> >> into
> >> > coreboot or BIOS machine.
> >>
> >> No UKI only works EFI systems.
> >>
> >
> > Can GRUB parse image and get kernel and initrd out of it and load like
> > Linux? What prevents add doing so. This is not a problem for this patch
> per
> > se but I want to understand
>
> If we aren't utilizing the EFI stub in the UKI, we could parse the kernel
> and
> initrd from the section data and load it from there. In that case, I
> suppose
> it would be possible to load it for a coreboot or BIOS machine.
>
I propose then to have some kind of "uki" command which would map to EFI
chainloader for now and later we can add implementation for non-EFI.

>
> >
> >>
> >> >>
> >> > What's the purpose of fallback? It's not what user/script has
> requested.
> >> It
> >> > needs to be at very least disableable
> >>
> >> The fallback code was from some of the old blscfg code I was working
> with
> >> and
> >> I added the UKI default directory. I'll add an option in case the user
> >> wants
> >> this behavior.
> >>
> >> >
> >> >>
> >> >>
> >> >> +   }
> >> >> +  else if (cmd_type == GRUB_UKI_CMD)
> >> >> +   {
> >> >> +#ifdef GRUB_MACHINE_EFI
> >> >> + grub_efi_loaded_image_t *image;
> >> >> + image = grub_efi_get_loaded_image (grub_efi_image_handle);
> >> >> + devid = grub_efidisk_get_device_name
> (image->device_handle);
> >> >> +#endif
> >> >>
> >> > This uses grub image location. What about a scenario when booted from
> >> > external drive and I want to boot into install on primary disk?
> >>
> >> Maybe I might not understand this scenario very well, but would it be
> >> better
> >> to load the UKI directory using the "--path" option? This bit of code is
> >> trying to locate the EFI system partition of the default directory. I'm
> not
> >> entirely sure the best way to find the default directory if it were to
> be
> >> on
> >> a different drive.
> >>
> > Does --path disable default path scanning?
>
> In this version, it does not. But in the newest version, I've added an
> option
> to enable or disable a fallback that would scan for the default path.
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] efi/mm: relax memory type request we're asking for from allocate_pages()

[Vladimir 'phcoder' Serbinenko]

Le jeu. 17 avr. 2025, 00:09, Vladimir 'phcoder' Serbinenko <
phco...@gmail.com> a écrit :

>
>> > If so I see a solution in having a code that would check paging table
>> and
>> > then decide on maximum usable memory
>>
>> any other arch doing this that i can imitate?
>>
> None currently. It could look like something along the lines:
> * Allocate pages
> * Check that they are mapped properly
> * If not, add missing pagetable entries.
>
I made a draft of a new workaround:
https://github.com/phcoder/GRUB/commit/2205039c48883c1a214c2a2e2f74f3f3e0907505

Testing it is a problem as original report dates back to 2011 and it's
impossible to know if any newer system is affected. I guess I'll have to
modify tianocore to have this bug.



>
>> --
>>
>>Paymon
>>
>> ___
>> 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] efi/mm: relax memory type request we're asking for from allocate_pages()

[Vladimir 'phcoder' Serbinenko]

>
>
> > If so I see a solution in having a code that would check paging table and
> > then decide on maximum usable memory
>
> any other arch doing this that i can imitate?
>
None currently. It could look like something along the lines:
* Allocate pages
* Check that they are mapped properly
* If not, add missing pagetable entries.


> --
>
>Paymon
>
> ___
> 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] efi/mm: relax memory type request we're asking for from allocate_pages()

[Vladimir 'phcoder' Serbinenko]

This will break systems that have a bug of mapping only 4GiB of RAM. This
code is a workaround for that bug. Which system do you use? Is it an x64?
If so I see a solution in having a code that would check paging table and
then decide on maximum usable memory

Regards
Vladimir 'phcoder' Serbinenko

Le mer. 16 avr. 2025, 23:00, Paymon MARANDI  a
écrit :

> this basically comes down to this in the specs:
>
> - Allocation requests of Type AllocateMaxAddress allocate any available
> range
>   of pages whose uppermost address is less than or equal to the address
> pointed
>   to by Memory on input. (this returns EFI_OUT_OF_RESOURCEST on loading
>   slightly large, 710MB, kernel images)
>
> + Allocation requests of Type AllocateAnyPages allocate any available
> range of
>   pages that satisfies the request. On input, the address pointed to by
> Memory
>   is ignored.
>
> Signed-off-by: Paymon MARANDI 
> ---
>  grub-core/kern/efi/mm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
> index df238b165..782b08099 100644
> --- a/grub-core/kern/efi/mm.c
> +++ b/grub-core/kern/efi/mm.c
> @@ -169,7 +169,7 @@ void *
>  grub_efi_allocate_any_pages (grub_efi_uintn_t pages)
>  {
>return grub_efi_allocate_pages_real (GRUB_EFI_MAX_USABLE_ADDRESS,
> -  pages,
> GRUB_EFI_ALLOCATE_MAX_ADDRESS,
> +  pages, GRUB_EFI_ALLOCATE_ANY_PAGES,
>GRUB_EFI_LOADER_DATA);
>  }
>
> --
> 2.49.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

Re: [PATCH] i386: Reduce the time of set VESA mode by clearing FB directly for Zhaoxin/Glenfly card

[Vladimir 'phcoder' Serbinenko]

Le lun. 14 avr. 2025, 05:38, Tony W Wang-oc  a
écrit :

> While calling VBIOS to set VESA mode, BIOS/GRUB can indicate VBIOS to clear
> frame buffer, it can also indicate VBIOS to skip this and do the clearing
> itself by access linear frame buffer directly.
>
> Zhaoxin/Glenfly VBIOS is running at real mode and can only access the first
> 1M memory, which means it can't access linear frame buffer directly. So the
> first way will take more time.
>
Can you add this explanation to the comment above or inside the if?
Otherwise Reviewed-By: Vladimir Serbinenko 
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 1/2] Include function name on debug traces

[Vladimir 'phcoder' Serbinenko]

What is the code size increase on i386-pc? Did you test it? This is likely
to result in a big one

Regards
Vladimir 'phcoder' Serbinenko

Le sam. 12 avr. 2025, 01:03, Leo Sandoval via Grub-devel 
a écrit :

> Together with the line number, the debug trace with the function name
> provides a bit more context and could be useful when inspecting log.
>
> Signed-off-by: Leo Sandoval 
> ---
>  grub-core/kern/misc.c | 4 ++--
>  include/grub/misc.h   | 5 +++--
>  2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/grub-core/kern/misc.c b/grub-core/kern/misc.c
> index 2b79223935..90c71d7cea 100644
> --- a/grub-core/kern/misc.c
> +++ b/grub-core/kern/misc.c
> @@ -231,14 +231,14 @@ grub_debug_enabled (const char * condition)
>  }
>
>  void
> -grub_real_dprintf (const char *file, const int line, const char
> *condition,
> +grub_real_dprintf (const char *file, const char *function, const int
> line, const char *condition,
>const char *fmt, ...)
>  {
>va_list args;
>
>if (grub_debug_enabled (condition))
>  {
> -  grub_printf ("%s:%d:%s: ", file, line, condition);
> +  grub_printf ("%s:%s:%d:%s: ", file, function, line, condition);
>va_start (args, fmt);
>grub_vprintf (fmt, args);
>va_end (args);
> diff --git a/include/grub/misc.h b/include/grub/misc.h
> index e087e7b3e8..881af5ca98 100644
> --- a/include/grub/misc.h
> +++ b/include/grub/misc.h
> @@ -35,7 +35,7 @@
>  #define ARRAY_SIZE(array) (sizeof (array) / sizeof (array[0]))
>  #define COMPILE_TIME_ASSERT(cond) switch (0) { case 1: case !(cond): ; }
>
> -#define grub_dprintf(condition, ...) grub_real_dprintf(GRUB_FILE,
> __LINE__, condition, __VA_ARGS__)
> +#define grub_dprintf(condition, ...) grub_real_dprintf(GRUB_FILE,
> __FUNCTION__, __LINE__, condition, __VA_ARGS__)
>
>  void *EXPORT_FUNC(grub_memmove) (void *dest, const void *src, grub_size_t
> n);
>  char *EXPORT_FUNC(grub_strcpy) (char *dest, const char *src);
> @@ -410,9 +410,10 @@ grub_puts (const char *s)
>  int EXPORT_FUNC(grub_puts_) (const char *s);
>  int EXPORT_FUNC(grub_debug_enabled) (const char *condition);
>  void EXPORT_FUNC(grub_real_dprintf) (const char *file,
> + const int function,
>   const int line,
>   const char *condition,
> - const char *fmt, ...) __attribute__
> ((format (GNU_PRINTF, 4, 5)));
> + const char *fmt, ...) __attribute__
> ((format (GNU_PRINTF, 5, 6)));
>  int EXPORT_FUNC(grub_printf) (const char *fmt, ...) __attribute__
> ((format (GNU_PRINTF, 1, 2)));
>  int EXPORT_FUNC(grub_printf_) (const char *fmt, ...) __attribute__
> ((format (GNU_PRINTF, 1, 2)));
>  int EXPORT_FUNC(grub_vprintf) (const char *fmt, va_list args);
> --
> 2.48.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 v1] grub-probe: detect DDF container similar to IMSM

[Vladimir 'phcoder' Serbinenko]

Le ven. 21 juin 2024, 11:21, Renaud Métrich  a écrit :

> DDF and IMSM are very similar in handling, especially these should not
> be considered as RAID abstraction.
> This fixes the requirement of having a device map when probing DDF
> containers.
>
Do you mean that DDF is handled by BIOS/UEFI? If so, looks good. Can you
add this to commit message?

>
> Fixes https://issues.redhat.com/browse/RHEL-44336
>
> Signed-off-by: Renaud Métrich 
> ---
>  grub-core/osdep/linux/getroot.c | 19 +--
>  1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/grub-core/osdep/linux/getroot.c
> b/grub-core/osdep/linux/getroot.c
> index 7dd775d2a..0c6c12945 100644
> --- a/grub-core/osdep/linux/getroot.c
> +++ b/grub-core/osdep/linux/getroot.c
> @@ -119,7 +119,7 @@ struct btrfs_ioctl_search_args {
> struct btrfs_ioctl_fs_info_args)
>
>  static int
> -grub_util_is_imsm (const char *os_dev);
> +grub_util_is_imsm_or_ddf (const char *os_dev);
>
>
>  #define ESCAPED_PATH_MAX (4 * PATH_MAX)
> @@ -635,10 +635,10 @@ out:
>  }
>
>  static int
> -grub_util_is_imsm (const char *os_dev)
> +grub_util_is_imsm_or_ddf (const char *os_dev)
>  {
>int retry;
> -  int is_imsm = 0;
> +  int is_imsm_or_ddf = 0;
>int container_seen = 0;
>const char *dev = os_dev;
>
> @@ -699,10 +699,17 @@ grub_util_is_imsm (const char *os_dev)
>   if (strncmp (buf, "MD_METADATA=imsm",
>sizeof ("MD_METADATA=imsm") - 1) == 0)
> {
> - is_imsm = 1;
> + is_imsm_or_ddf = 1;
>   grub_util_info ("%s is imsm", dev);
>   break;
> }
> + if (strncmp (buf, "MD_METADATA=ddf",
> +  sizeof ("MD_METADATA=ddf") - 1) == 0)
> +   {
> + is_imsm_or_ddf = 1;
> + grub_util_info ("%s is ddf", dev);
> + break;
> +   }
> }
>
>free (buf);
> @@ -713,7 +720,7 @@ grub_util_is_imsm (const char *os_dev)
>
>if (dev != os_dev)
>  free ((void *) dev);
> -  return is_imsm;
> +  return is_imsm_or_ddf;
>  }
>
>  char *
> @@ -1078,7 +1085,7 @@ grub_util_get_dev_abstraction_os (const char *os_dev)
>
>/* Check for RAID.  */
>if (!strncmp (os_dev, "/dev/md", 7) && ! grub_util_device_is_mapped
> (os_dev)
> -  && !grub_util_is_imsm (os_dev))
> +  && !grub_util_is_imsm_or_ddf (os_dev))
>  return GRUB_DEV_ABSTRACTION_RAID;
>return GRUB_DEV_ABSTRACTION_NONE;
>  }
> --
> 2.45.2
>
>
> ___
> 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 v1] grub-probe: detect DDF container similar to IMSM

[Vladimir 'phcoder' Serbinenko]

Thank you for bringing this up

Regards
Vladimir 'phcoder' Serbinenko

Le lun. 14 avr. 2025, 12:25, Marta Lewandowska via Grub-devel <
grub-devel@gnu.org> a écrit :

> Hi Daniel, Vladimir,
> Could one of you please provide some feedback for Renaud's patch..?
>
> thanks!
> marta
>
> On Fri, Jun 21, 2024 at 10:21 AM Renaud Métrich 
> wrote:
>
>> DDF and IMSM are very similar in handling, especially these should not
>> be considered as RAID abstraction.
>> This fixes the requirement of having a device map when probing DDF
>> containers.
>>
>> Fixes https://issues.redhat.com/browse/RHEL-44336
>>
>> Signed-off-by: Renaud Métrich 
>> ---
>>  grub-core/osdep/linux/getroot.c | 19 +--
>>  1 file changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/grub-core/osdep/linux/getroot.c
>> b/grub-core/osdep/linux/getroot.c
>> index 7dd775d2a..0c6c12945 100644
>> --- a/grub-core/osdep/linux/getroot.c
>> +++ b/grub-core/osdep/linux/getroot.c
>> @@ -119,7 +119,7 @@ struct btrfs_ioctl_search_args {
>> struct btrfs_ioctl_fs_info_args)
>>
>>  static int
>> -grub_util_is_imsm (const char *os_dev);
>> +grub_util_is_imsm_or_ddf (const char *os_dev);
>>
>>
>>  #define ESCAPED_PATH_MAX (4 * PATH_MAX)
>> @@ -635,10 +635,10 @@ out:
>>  }
>>
>>  static int
>> -grub_util_is_imsm (const char *os_dev)
>> +grub_util_is_imsm_or_ddf (const char *os_dev)
>>  {
>>int retry;
>> -  int is_imsm = 0;
>> +  int is_imsm_or_ddf = 0;
>>int container_seen = 0;
>>const char *dev = os_dev;
>>
>> @@ -699,10 +699,17 @@ grub_util_is_imsm (const char *os_dev)
>>   if (strncmp (buf, "MD_METADATA=imsm",
>>sizeof ("MD_METADATA=imsm") - 1) == 0)
>> {
>> - is_imsm = 1;
>> + is_imsm_or_ddf = 1;
>>   grub_util_info ("%s is imsm", dev);
>>   break;
>> }
>> + if (strncmp (buf, "MD_METADATA=ddf",
>> +  sizeof ("MD_METADATA=ddf") - 1) == 0)
>> +   {
>> + is_imsm_or_ddf = 1;
>> + grub_util_info ("%s is ddf", dev);
>> + break;
>> +   }
>> }
>>
>>free (buf);
>> @@ -713,7 +720,7 @@ grub_util_is_imsm (const char *os_dev)
>>
>>if (dev != os_dev)
>>  free ((void *) dev);
>> -  return is_imsm;
>> +  return is_imsm_or_ddf;
>>  }
>>
>>  char *
>> @@ -1078,7 +1085,7 @@ grub_util_get_dev_abstraction_os (const char
>> *os_dev)
>>
>>/* Check for RAID.  */
>>if (!strncmp (os_dev, "/dev/md", 7) && ! grub_util_device_is_mapped
>> (os_dev)
>> -  && !grub_util_is_imsm (os_dev))
>> +  && !grub_util_is_imsm_or_ddf (os_dev))
>>  return GRUB_DEV_ABSTRACTION_RAID;
>>return GRUB_DEV_ABSTRACTION_NONE;
>>  }
>> --
>> 2.45.2
>>
>>
>> ___
>> 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
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] kern/efi/mm: try allocating in the lower 4GB first

[Vladimir 'phcoder' Serbinenko]

How early is this bug? Do you see "Welcome to GRUB"? Does recompiling with
fPIC help? Do you have memory map dump and paging table dump?

Regards
Vladimir 'phcoder' Serbinenko

Le ven. 11 avr. 2025, 13:39, Tobias Heider  a
écrit :

> On arm64 we can't restrict memory usage below 0x as we do
> on x86 because there is no guarantee memory in that range exists
> at all (an example is Apple Silicon).
> Instead, try to allocate in the lower 4GB range first and fall
> back to the entire available address space if that did not work.
>
> This fixes a bug on Snapdragon X Elite devices such as the Lenovo
> Thinkpad T14s which crashes when accessing memory above 0x.
>
> Signed-off-by: Tobias Heider 
> ---
>
>  For previous discussion see
>  https://lists.gnu.org/archive/html/grub-devel/2025-04/msg00072.html
>
>  In contrast to the previous patch this one affects all archs.
>  It seems generally safe not to limit it to arm64 with the fallback
>  to the old behaviour but I'd be interested to hear if there are any
>  concerns.
>  Tested on a Snapdragon X Elite and Macbook M2 Air.
>
>  grub-core/kern/efi/mm.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
> index df238b165..029d975dd 100644
> --- a/grub-core/kern/efi/mm.c
> +++ b/grub-core/kern/efi/mm.c
> @@ -168,9 +168,19 @@ grub_efi_allocate_pages_real
> (grub_efi_physical_address_t address,
>  void *
>  grub_efi_allocate_any_pages (grub_efi_uintn_t pages)
>  {
> -  return grub_efi_allocate_pages_real (GRUB_EFI_MAX_USABLE_ADDRESS,
> -  pages,
> GRUB_EFI_ALLOCATE_MAX_ADDRESS,
> -  GRUB_EFI_LOADER_DATA);
> +  void *ret;
> +
> +  ret = grub_efi_allocate_pages_real (0x,
> + pages, GRUB_EFI_ALLOCATE_MAX_ADDRESS,
> + GRUB_EFI_LOADER_DATA);
> +  if (ret == NULL)
> +{
> +  grub_errno = GRUB_ERR_NONE;
> +  ret = grub_efi_allocate_pages_real (GRUB_EFI_MAX_USABLE_ADDRESS,
> + pages,
> GRUB_EFI_ALLOCATE_MAX_ADDRESS,
> + GRUB_EFI_LOADER_DATA);
> +}
> +  return ret;
>  }
>
>  void *
> --
> 2.48.1
>
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] ia64: Disable optimizations using floating-point arithmetics

[Vladimir 'phcoder' Serbinenko]

Regards
Vladimir 'phcoder' Serbinenko

Le jeu. 10 avr. 2025, 18:32, Daniel Kiper  a écrit :

> On Thu, Apr 10, 2025 at 01:45:37PM +0300, Vladimir Serbinenko wrote:
> > They don't work in ski emulator and we don't really need them
> >
> > Signed-off-by: Vladimir Serbinenko 
> > ---
> >  configure.ac| 4 ++--
> >  grub-core/Makefile.core.def | 2 +-
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/configure.ac b/configure.ac
> > index 25f3ff932..ecb8bc666 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -933,9 +933,9 @@ if test x"$platform" != xemu ; then
> >
> [grub_cv_target_cc_soft_float="-march=rv64imac_zicsr_zifencei -mabi=lp64"],
> [])
> >  fi
> >  if test "x$target_cpu" = xia64; then
> > -   CFLAGS="$TARGET_CFLAGS -mno-inline-float-divide -mno-inline-sqrt
> -Werror"
> > +   CFLAGS="$TARGET_CFLAGS -mno-inline-int-divide
> -mno-inline-float-divide -mno-inline-sqrt -Werror"
> > AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],
> > -
> [grub_cv_target_cc_soft_float="-mno-inline-float-divide -mno-inline-sqrt"],
> [])
> > +
> [grub_cv_target_cc_soft_float="-mno-inline-int-divide
> -mno-inline-float-divide -mno-inline-sqrt"], [])
>
> I think you are dealing with int instead of float. I suppose the subject
> has to be fixed.
>
-minline-int-divide replaced integer divisions with floating point
operations. So it does use for arithmetic despite its name


> Daniel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] arm64: Limit memory allocations to 4GB boundary

[Vladimir 'phcoder' Serbinenko]

Why does it crash? Is it because of MMU or is it because of relocations?
Arm is trickier than x64 add we can't be sure that there is any memory
under 4GiB mark. Entire memory may be married above 4GiB

Le lun. 7 avr. 2025, 21:31, Tobias Heider  a
écrit :

> Some Qualcomm Snapdragon X Elite based machines like the Lenovo Thinkpad
> T14s
> crash when trying to use memory above 0x.
> Enforcing the same 4GB limit as we do on x86_64 fixes the issue.
>
> Signed-off-by: Tobias Heider 
> ---
>  include/grub/arm64/efi/memory.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/grub/arm64/efi/memory.h
> b/include/grub/arm64/efi/memory.h
> index c6cb32417..2c64918e3 100644
> --- a/include/grub/arm64/efi/memory.h
> +++ b/include/grub/arm64/efi/memory.h
> @@ -1,6 +1,6 @@
>  #ifndef GRUB_MEMORY_CPU_HEADER
>  #include 
>
> -#define GRUB_EFI_MAX_USABLE_ADDRESS 0xULL
> +#define GRUB_EFI_MAX_USABLE_ADDRESS 0x
>
>  #endif /* ! GRUB_MEMORY_CPU_HEADER */
> --
> 2.48.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: [RFC] Rust in GRUB

[Vladimir 'phcoder' Serbinenko]

I understand your frustration and I share it and will try to do as much as
reasonable to decrease amount of carried patches. Rust experiments do not
and should not take over release and patch integration work. They are
independent and effort for rust is minimal. Please put discussion about
topics other than Rust in a different thread.

Le sam. 22 mars 2025, 16:43, Didier Spaier via Grub-devel <
grub-devel@gnu.org> a écrit :

> On 22/03/2025 09:42, Maxim Fomin wrote:
> > On Friday, March 21st, 2025 at 8:51 PM, Vladimir 'phcoder' Serbinenko <
> phco...@gmail.com> wrote:
> >
> >> Hello, I was playing with adding Rust embedded in GRUB. I’ve pushed
> results to 2 repos:
> >> Module goes to https://github.com/phcoder/grub-rust-hello/tree/master
> >> Changes in GRUB are found at https://github.com/phcoder/GRUB/tree/rust
> >> Notes on implementation:
> >> Only i386-pc is implemented right now but it’s not a technical limit,
> just others are not implemented yet.
> >> I changed GRUB to use ET_DYN (.so) binaries as modules instead of
> ET_REL (.o).
> >> I disabled mregparm=3. -Z regparm=3 in Rust generally works but the
> calls to memcpy() still uses regparm=0 calling convention. Perhaps it’s a
> bug on Rust side, perhaps we need an adapter on our side.
> >> It’s compiled with panic=abort. Unwinding panics require
> rust_eh_personality that isn’t implemented yet.
> >> src/lib.rs is an example of hello world and grub_lib.rs is a grub-rust
> adapter. Ideally they should be in separate crates
> >> Every module now pulls in rust runtime. Idk how to switch to a shared
> runtime
> >> Consider it more an experiment and request for comments than a working
> product. I would be interested to hear any comments. Especially it’s
> interesting to hear from Rust folks as to how to make it more idiomatic
> Rust.
> >
> > I found it indicative that the post about introducing Rust into the
> project lacks any technical discussion about the merits of doing so. This
> agrees with the Rust criticism point that bringing Rust into project is
> often caused by programmers wanting to show off ("me/project is cool
> because it has Rust") rather than technical merits.
> >
> > Best regards,
> > Maxim Fomin
>
> Hello,
>
> by lack of knowledge I have no idea about merits of rust compared to any
> other
> programming language.
>
> Generally speaking my wish as an end user and packager is that providing a
> new
> stable release takes priority over any enhancement or addition of new
> features.
>
> Maybe not an issue for Debian, but how many distributions have the
> resources
> needed to check and carry hundreds of patches?
>
> Cheers,
> Didier
>
> ___
> 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: [RESEND PATCH 1/1] loader/efi/chainloader: Enhance error messages in chainloader command

[Vladimir 'phcoder' Serbinenko]

Le ven. 4 avr. 2025, 00:25, khaliid caliy  a écrit :

> Well i apologies the error message were somehow bad on my previous
> patch, and needed some improvement.
>
> diff --git a/grub-core/loader/efi/chainloader.c
> b/grub-core/loader/efi/chainloader.c
> index 869307bf3..4fd46dfda 100644
> --- a/grub-core/loader/efi/chainloader.c
> +++ b/grub-core/loader/efi/chainloader.c
> @@ -346,6 +346,12 @@ grub_cmd_chainloader (grub_command_t cmd
> __attribute__ ((unused)),
> {
>   if (status == GRUB_EFI_OUT_OF_RESOURCES)
>grub_error (GRUB_ERR_OUT_OF_MEMORY, "out of resources");
> +  else if (status == GRUB_EFI_INVALID_PARAMETER)
> +   grub_error (GRUB_ERR_BAD_ARGUMENT, "the image supplied
> paramters are invalid");
>
Typo

> +  else if (status == GRUB_EFI_NOT_FOUND)
> +   grub_error (GRUB_ERR_FILE_NOT_FOUND, "the image not found");
> +  else if (status == GRUB_EFI_UNSUPPORTED)
> +   grub_error (GRUB_ERR_BAD_OS, "grub doesn't support this image");
>
This has nothing to do with what GRUB supports. It's about what firmware
supports.

How did you choose which error codes to translate? Did you actually see
them? Are those distinctions useful without knowing EFI spec? Maybe it's
better to just print EFI error in hex?

>   else
>grub_error (GRUB_ERR_BAD_OS, "cannot load image");
>
> ___
> 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] kern/x86_64/efi/startup: Suggestion in the startup code

[Vladimir 'phcoder' Serbinenko]

Call results in a nicer stacktrace. And 2 cycles is nothing in the context
of them being executed only once

Le ven. 4 avr. 2025, 16:45, khaliid caliy  a écrit :

> Just simple suggestion, i still don't know the reason behind it. So
> please if isn't ideal, i apologies
>
> My suggestion is since the `grub_main` doesn't return to the low level
> assembly code, why didn't get used `jmp` instruction instead of
> `call`. I think in this context jmp is slightly better than call,
> about 2 cycles faster. While this isn't match,  but it will at least
> resolve some confusion. Other than that the boot process is fine and
> no issues.
>
> Patch
> diff --git a/grub-core/kern/x86_64/efi/startup.S
> b/grub-core/kern/x86_64/efi/startup.S
> index 9357e5c5d..a51b07427 100644
> --- a/grub-core/kern/x86_64/efi/startup.S
> +++ b/grub-core/kern/x86_64/efi/startup.S
> @@ -31,5 +31,4 @@ _start:
>movq%rdx, EXT_C(grub_efi_system_table)(%rip)
>
>andq$~0xf, %rsp
> -   callEXT_C(grub_main)
> -   /* Doesn't return.  */
> +   jmp EXT_C(grub_main)
>
> If there is a reason other than that i mentioned above, then please let me
> know.
>
> Best Regards
> khaalid cali
>
> ___
> 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 5/7] keccak: Disable acceleration with SSE asm

[Vladimir 'phcoder' Serbinenko]

Le jeu. 3 avr. 2025, 18:06, Daniel Kiper  a écrit :

> On Tue, Apr 01, 2025 at 03:58:56PM +0300, Vladimir Serbinenko wrote:
> > Libgcrypt code assumes that on x64 all SSE registers are fair game.
> > While it's true that CPUs in question support it, we disable it in
> > our compilation options. Disable the offending optimization.
> >
> > Signed-off-by: Vladimir Serbinenko 
> > ---
> >  .../lib/libgcrypt-patches/02_keccak_sse.patch | 23 +++
> >  1 file changed, 23 insertions(+)
> >  create mode 100644 grub-core/lib/libgcrypt-patches/02_keccak_sse.patch
> >
> > diff --git a/grub-core/lib/libgcrypt-patches/02_keccak_sse.patch
> b/grub-core/lib/libgcrypt-patches/02_keccak_sse.patch
> > new file mode 100644
> > index 0..c153518da
> > --- /dev/null
> > +++ b/grub-core/lib/libgcrypt-patches/02_keccak_sse.patch
> > @@ -0,0 +1,23 @@
> > +commit b0cf06271da5fe20360953a53a47c69da89669cd
> > +Author: Vladimir Serbinenko 
> > +Date:   Sun Apr 7 06:33:11 2024 +0300
> > +
> > +keccak: Disable acceleration with SSE asm
> > +
> > +Libgcrypt code assumes that on x64 all SSE registers are fair game.
> > +While it's true that CPUs in question support it, we disable it in
> > +our compilation options. Disable the offending optimization.
>
> Please add your SOB here too. If you do that you can add
> Reviewed-by: Daniel Kiper  here and above...
>
> And it would be nice if you fix these warnings:
>
>   Applying: keccak: Disable acceleration with SSE asm
>   .git/rebase-apply/patch:29: trailing whitespace.
>
>   .git/rebase-apply/patch:32: trailing whitespace.
>
>   warning: 2 lines add whitespace errors.
>
Impossible without breaking the patch

>
> Daniel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 6/7] libgcrypt: Fix coverity warnings

[Vladimir 'phcoder' Serbinenko]

Le jeu. 3 avr. 2025, 18:19, Daniel Kiper  a écrit :

> On Tue, Apr 01, 2025 at 03:58:57PM +0300, Vladimir Serbinenko wrote:
>
> Please split this patch into (probably) three and add CID to each one.
> Good example is in commit 4dc616657 (loader/i386/bsd: Use safe math to
> avoid underflow). Of course patches should land in
> grub-core/lib/libgcrypt-patches.
>
Done

>
> Did you report these issues to libgcrypt maintainers?
>
Not yet

>
> And...
>
>   Applying: libgcrypt: Fix coverity warnings
>   .git/rebase-apply/patch:17: space before tab in indent.
>   int n = (a->sign+7)/8;
>   .git/rebase-apply/patch:18: space before tab in indent.
>   void *p = _gcry_is_secure(a->d)? xtrymalloc_secure (n)
>   .git/rebase-apply/patch:23: space before tab in indent.
>   memcpy( p, a->d, n );
>   .git/rebase-apply/patch:24: space before tab in indent.
>   b = mpi_set_opaque( NULL, p, a->sign );
>   .git/rebase-apply/patch:33: trailing whitespace.
>
>   warning: squelched 2 whitespace errors
>   warning: 7 lines add whitespace errors.
>
> By the way, when I run bootstrap I can these warnings:
>
>   Importing libgcrypt...
>   WARNING: C file isn't a module: blake2.c
>   WARNING: C file isn't a module: ecc-curves.c
>   WARNING: C file isn't a module: ecc-ecdh.c
>   WARNING: C file isn't a module: ecc-ecdsa.c
>   WARNING: C file isn't a module: ecc-eddsa.c
>   WARNING: C file isn't a module: ecc-gost.c
>   WARNING: C file isn't a module: ecc-misc.c
>   WARNING: C file isn't a module: ecc-sm2.c
>   WARNING: C file isn't a module: gost-s-box.c
>   WARNING: C file isn't a module: poly1305.c
>   WARNING: C file isn't a module: primegen.c
>
> Daniel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 4/7] Add DSA and RSA SEXP tests

[Vladimir 'phcoder' Serbinenko]

Le jeu. 3 avr. 2025, 17:59, Daniel Kiper  a écrit :

> On Tue, Apr 01, 2025 at 03:58:55PM +0300, Vladimir Serbinenko wrote:
> > This allows us to test purely the integration of the implementation
> > of DSA and RSA from libgcrypt without concerning with additional
> > code.
> >
> > Signed-off-by: Vladimir Serbinenko 
> > ---
> >  grub-core/tests/dsa_sexp_test.c | 125 
> >  grub-core/tests/rsa_sexp_test.c |  99 +
> >  2 files changed, 224 insertions(+)
> >  create mode 100644 grub-core/tests/dsa_sexp_test.c
> >  create mode 100644 grub-core/tests/rsa_sexp_test.c
> >
> > diff --git a/grub-core/tests/dsa_sexp_test.c
> b/grub-core/tests/dsa_sexp_test.c
> > new file mode 100644
> > index 0..5b7b7b143
> > --- /dev/null
> > +++ b/grub-core/tests/dsa_sexp_test.c
> > @@ -0,0 +1,125 @@
> > +/*
> > + *  GRUB  --  GRand Unified Bootloader
> > + *  Copyright (C) 2024 Free Software Foundation, Inc.
>
> s/2024/2025/
>
> Please fix the same issue in the second file too...
>
> > + *  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 .
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +GRUB_MOD_LICENSE ("GPLv3+");
> > +
> > +static char pubkey_dump[] = {
> > +  0x28, 0x31, 0x30, 0x3a, 0x70, 0x75, 0x62, 0x6c,
> > +  0x69, 0x63, 0x2d, 0x6b, 0x65, 0x79, 0x28, 0x33,
> > +  0x3a, 0x64, 0x73, 0x61, 0x28, 0x31, 0x3a, 0x70,
> > +  0x31, 0x32, 0x39, 0x3a, 0x00, 0xc0, 0x50, 0x14,
> > +  0x4c, 0x97, 0x10, 0x69, 0x07, 0xa7, 0xe9, 0x2b,
> > +  0xe5, 0xc6, 0x88, 0xe1, 0x6d, 0xd8, 0x38, 0x28,
> > +  0x09, 0x49, 0x5b, 0xe8, 0xa3, 0x04, 0xb8, 0xc4,
> > +  0x6e, 0x98, 0xc1, 0xc2, 0xb0, 0x2a, 0xe0, 0xe2,
> > +  0x1a, 0x30, 0xd2, 0xdb, 0x45, 0x1a, 0x88, 0x80,
> > +  0x28, 0x24, 0xb0, 0xbf, 0xc2, 0xbd, 0xe9, 0xf6,
> > +  0x9d, 0xa2, 0x01, 0x94, 0xe6, 0x7f, 0xa0, 0xb6,
> > +  0xe4, 0x39, 0xfc, 0x54, 0xba, 0x99, 0xb6, 0xbe,
> > +  0x39, 0xee, 0xa5, 0xd9, 0xa0, 0x35, 0x3c, 0x2d,
> > +  0x3e, 0x96, 0xc3, 0x96, 0xa5, 0x0d, 0x2b, 0xbf,
> > +  0x3b, 0xa3, 0xe2, 0xe8, 0x89, 0xed, 0x60, 0xe0,
> > +  0x43, 0x61, 0xb6, 0x73, 0xf6, 0xa7, 0xb4, 0x56,
> > +  0x76, 0x04, 0xf7, 0x8b, 0xf1, 0x84, 0xaa, 0x3e,
> > +  0xe0, 0x08, 0xad, 0xdd, 0xc2, 0x36, 0xfd, 0x3d,
> > +  0xd0, 0xad, 0xf4, 0x3a, 0x7e, 0x80, 0x8c, 0x52,
> > +  0x2b, 0x04, 0xa8, 0x03, 0x27, 0x29, 0x28, 0x31,
> > +  0x3a, 0x71, 0x32, 0x31, 0x3a, 0x00, 0xd5, 0x34,
> > +  0xd2, 0xc5, 0x1c, 0x26, 0xdf, 0xb0, 0xba, 0x78,
> > +  0x75, 0xe5, 0xe9, 0x36, 0x6b, 0x04, 0x03, 0xe2,
> > +  0x57, 0x3f, 0x29, 0x28, 0x31, 0x3a, 0x67, 0x31,
> > +  0x32, 0x38, 0x3a, 0x3b, 0xa0, 0xac, 0xa3, 0xa1,
> > +  0xd1, 0x04, 0x23, 0x5f, 0x9f, 0xbc, 0x6d, 0x9e,
> > +  0x88, 0x2a, 0x28, 0xc1, 0x48, 0xaf, 0xa5, 0x17,
> > +  0x59, 0x3a, 0x17, 0x33, 0x56, 0xaa, 0x8d, 0x27,
> > +  0x64, 0xfe, 0x8e, 0x8a, 0x2e, 0xba, 0xf2, 0x66,
> > +  0xcc, 0x66, 0xbd, 0xa4, 0xfe, 0xa9, 0x07, 0x0d,
> > +  0xae, 0x8c, 0x9f, 0x70, 0xf7, 0x87, 0xaa, 0x01,
> > +  0x47, 0x6b, 0xf9, 0x0f, 0x09, 0x18, 0x42, 0x76,
> > +  0xc4, 0xa3, 0xb9, 0x55, 0x11, 0x8d, 0xa3, 0xa5,
> > +  0x69, 0x30, 0x91, 0xb7, 0x03, 0xef, 0x7f, 0x12,
> > +  0xe6, 0xb9, 0x78, 0x73, 0xe0, 0xc0, 0x4f, 0xc6,
> > +  0xd9, 0x43, 0x99, 0x95, 0x0b, 0x4d, 0x58, 0xd3,
> > +  0x6b, 0x76, 0xb0, 0x6a, 0xcf, 0x68, 0x6d, 0xf0,
> > +  0xd9, 0xc1, 0x88, 0x43, 0x9d, 0xf9, 0x04, 0xcb,
> > +  0xc9, 0x82, 0x6c, 0xee, 0xd4, 0x9c, 0xbd, 0x1c,
> > +  0x4d, 0x54, 0x29, 0x83, 0xa9, 0x5e, 0xaa, 0x10,
> > +  0xa7, 0xc1, 0x04, 0x29, 0x28, 0x31, 0x3a, 0x79,
> > +  0x31, 0x32, 0x39, 0x3a, 0x00, 0x82, 0x33, 0xf1,
> > +  0x91, 0xe3, 0xf2, 0x12, 0x93, 0x5a, 0xed, 0x0c,
> > +  0x9d, 0xec, 0x67, 0xaa, 0xa7, 0x97, 0x7f, 0x9f,
> > +  0x5e, 0xef, 0x6a, 0x3e, 0xa4, 0x7f, 0x9b, 0xed,
> > +  0x65, 0xd7, 0xba, 0x40, 0x6d, 0xe1, 0xde, 0xc1,
> > +  0x14, 0x4c, 0x9b, 0x28, 0x5c, 0x03, 0x8e, 0x1a,
> > +  0xd4, 0x1b, 0x80, 0x1b, 0x07, 0xd6, 0x84, 0x04,
> > +  0x49, 0x6c, 0x1b, 0x08, 0x84, 0x15, 0x54, 0x62,
> > +  0xca, 0xd5, 0x75, 0xff, 0xc8, 0xb3, 0x81, 0x76,
> > +  0x82, 0x91, 0x35, 0x80, 0x20, 0x73, 0x2a, 0x21,
> > +  0xca, 0x22, 0x06, 0xa7, 0x73, 0x99, 0x75, 0x7e,
> > +  0x5e, 0xa6, 0x09, 0x59, 0x66, 0x2c, 0xcd, 0xb1,
> > +  0x8d, 0x3b, 0xc0, 0x68, 0xc5, 0x41, 0xa0, 0x9d,
> > +  0x82, 0x15, 0xc4, 0xdd, 0x47, 0x1c, 0x5b, 0xa9,
> > +  0x74, 0x18, 0xaf, 0x72, 0x63, 0x6b, 0x0a, 0x4e,
> > +  0x95, 0x09, 0x7a, 0xb5, 0x4b, 0x98, 0x85, 

Re: [PATCH 3/7] Adjust import script, definitions and API users for libgcrypt 1.10

[Vladimir 'phcoder' Serbinenko]

Le jeu. 3 avr. 2025, 17:51, Daniel Kiper  a écrit :

> On Tue, Apr 01, 2025 at 03:58:54PM +0300, Vladimir Serbinenko wrote:
>
> Missing commit message...
>
> Is it possible to split this patch into smaller ones?
>
> And should not these changes go to separate patches in
> grub-core/lib/libgcrypt-patches?
>
No, they are changes to GRUB, not libgcrypt

>
> Additionally, git complains in that way:
>
>   Applying: Adjust import script, definitions and API users for libgcrypt
> 1.10
>   .git/rebase-apply/patch:878: trailing whitespace.
>
>   .git/rebase-apply/patch:879: trailing whitespace.
>
>   .git/rebase-apply/patch:882: trailing whitespace.
>
>   .git/rebase-apply/patch:892: trailing whitespace.
>
>   .git/rebase-apply/patch:904: trailing whitespace.
>
>   warning: squelched 15 whitespace errors
>   warning: 20 lines add whitespace errors.
>
> Probably at least some of these issues could be fixed. If not all...
>
Those come from patches and space has special meaning in patches, so we
can't remove them

>
> Daniel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 1/7] Import libgcrypt 1.10.3

[Vladimir 'phcoder' Serbinenko]

Le jeu. 3 avr. 2025, 17:40, Daniel Kiper  a écrit :

> On Tue, Apr 01, 2025 at 03:58:52PM +0300, Vladimir Serbinenko wrote:
> > We currently use an old version of libcrypt which
> > results in us having fewer ciphers and missing on many
> > other improvements.
>
> Could you upgrade the libgcrypt to the latest version, i.e. 1.11.0?
>
Done
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH GRUB] fs/xfs: fix large extent counters incompat feature support

[Vladimir 'phcoder' Serbinenko]

Reviewed-By : Vladimir Serbinenko phco...@gmail.com

Le mer. 4 déc. 2024, 17:12, Eric Sandeen  a écrit :

> When large extent counter / NREXT64 support was added to grub, it missed
> a couple of direct reads of nextents which need to be changed to the new
> NREXT64-aware helper as well. Without this, we'll have mis-reads of some
> directories with this feature enabled.
>
> (The large extent counter fix likely raced on merge with
> 07318ee7e ("fs/xfs: Fix XFS directory extent parsing") which added the new
> direct nextents reads just prior, causing this issue.)
>
> Fixes: aa7c1322671e ("fs/xfs: Add large extent counters incompat feature
> support")
> Signed-off-by: Eric Sandeen 
> ---
>
> diff --git a/grub-core/fs/xfs.c b/grub-core/fs/xfs.c
> index 8e02ab4a3..92046f9bd 100644
> --- a/grub-core/fs/xfs.c
> +++ b/grub-core/fs/xfs.c
> @@ -926,7 +926,7 @@ grub_xfs_iterate_dir (grub_fshelp_node_t dir,
>  * Leaf and tail information are only in the data block if the
> number
>  * of extents is 1.
>  */
> -   if (dir->inode.nextents == grub_cpu_to_be32_compile_time (1))
> +   if (grub_xfs_get_inode_nextents(&dir->inode) == 1)
>   {
> struct grub_xfs_dirblock_tail *tail = grub_xfs_dir_tail
> (dir->data, dirblock);
>
> @@ -980,7 +980,7 @@ grub_xfs_iterate_dir (grub_fshelp_node_t dir,
>  * The expected number of directory entries is only
> tracked for the
>  * single extent case.
>  */
> -   if (dir->inode.nextents == grub_cpu_to_be32_compile_time
> (1))
> +   if (grub_xfs_get_inode_nextents(&dir->inode) == 1)
>   {
> /* Check if last direntry in this block is reached. */
> entries--;
>
>
> ___
> 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 3/3] blsuki: Add uki command to load Unified Kernel Image entries

[Vladimir 'phcoder' Serbinenko]

Le jeu. 27 mars 2025, 23:44, Alec Brown  a écrit :

> On Wed, Mar 26, 2025 at 5:43 AM, Vladimir 'phcoder' Serbinenko <
> phco...@gmail.com> wrote:
> >>
> >>
> >>
> >> +#ifdef GRUB_MACHINE_EFI
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#endif
> >> +
> >>
> > Can UKI work without EFI? I think of scenario of putting e.g. EFI disk
> into
> > coreboot or BIOS machine.
>
> No UKI only works EFI systems.
>

Can GRUB parse image and get kernel and initrd out of it and load like
Linux? What prevents add doing so. This is not a problem for this patch per
se but I want to understand

>
> >>
> > What's the purpose of fallback? It's not what user/script has requested.
> It
> > needs to be at very least disableable
>
> The fallback code was from some of the old blscfg code I was working with
> and
> I added the UKI default directory. I'll add an option in case the user
> wants
> this behavior.
>
> >
> >>
> >>
> >> +   }
> >> +  else if (cmd_type == GRUB_UKI_CMD)
> >> +   {
> >> +#ifdef GRUB_MACHINE_EFI
> >> + grub_efi_loaded_image_t *image;
> >> + image = grub_efi_get_loaded_image (grub_efi_image_handle);
> >> + devid = grub_efidisk_get_device_name (image->device_handle);
> >> +#endif
> >>
> > This uses grub image location. What about a scenario when booted from
> > external drive and I want to boot into install on primary disk?
>
> Maybe I might not understand this scenario very well, but would it be
> better
> to load the UKI directory using the "--path" option? This bit of code is
> trying to locate the EFI system partition of the default directory. I'm not
> entirely sure the best way to find the default directory if it were to be
> on
> a different drive.
>
Does --path disable default path scanning?
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 3/5] loader/i386/linux: Fix resource leak

[Vladimir 'phcoder' Serbinenko]

>
>
> +  {
> +   grub_errno = err;
> +   goto fail;
> +  }
>
grub_errno is already set. No need to set it again

>  initrd_mem = get_virtual_current_address (ch);
>  initrd_mem_target = get_physical_target_address (ch);
>}
> --
> 2.34.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 1/5] disk/ldm: Fix memory leaks

[Vladimir 'phcoder' Serbinenko]

Reviewed-By : Vladimir Serbinenko

Le jeu. 27 mars 2025, 20:57, Lidong Chen via Grub-devel 
a écrit :

> Fix memory leaks in make_vg() with new helper functions, free_pv()
> and free_lv(). Additionally, correct a check after allocating
> comp->segments->nodes that mistakenly checked lv->segments->nodes
> instead, likely due to a copy-paste error.
>
> Fixes: CID 473878
> Fixes: CID 473884
> Fixes: CID 473889
> Fixes: CID 473890
>
> Signed-off-by: Lidong Chen 
> ---
>  grub-core/disk/ldm.c | 180 +++
>  1 file changed, 80 insertions(+), 100 deletions(-)
>
> diff --git a/grub-core/disk/ldm.c b/grub-core/disk/ldm.c
> index 048e29cd0..0f4f22aaa 100644
> --- a/grub-core/disk/ldm.c
> +++ b/grub-core/disk/ldm.c
> @@ -179,6 +179,36 @@ gpt_ldm_sector (grub_disk_t dsk)
>return sector;
>  }
>
> +static void
> +free_pv (struct grub_diskfilter_pv *pv)
> +{
> +  if (pv == NULL)
> +return;
> +
> +  grub_free (pv->internal_id);
> +  grub_free (pv->id.uuid);
> +  grub_free (pv);
> +}
> +
> +static void
> +free_lv (struct grub_diskfilter_lv *lv)
> +{
> +  if (lv == NULL)
> +return;
> +
> +  grub_free (lv->internal_id);
> +  grub_free (lv->name);
> +  grub_free (lv->fullname);
> +  if (lv->segments)
> +{
> +  unsigned int i;
> +  for (i = 0; i < lv->segment_count; i++)
> +   grub_free (lv->segments[i].nodes);
> +  grub_free (lv->segments);
> +}
> +  grub_free (lv);
> +}
> +
>  static struct grub_diskfilter_vg *
>  make_vg (grub_disk_t disk,
>  const struct grub_ldm_label *label)
> @@ -196,12 +226,8 @@ make_vg (grub_disk_t disk,
>vg->name = grub_malloc (LDM_NAME_STRLEN + 1);
>vg->uuid = grub_malloc (LDM_GUID_STRLEN + 1);
>if (! vg->uuid || !vg->name)
> -{
> -  grub_free (vg->uuid);
> -  grub_free (vg->name);
> -  grub_free (vg);
> -  return NULL;
> -}
> +goto fail1;
> +
>grub_memcpy (vg->uuid, label->group_guid, LDM_GUID_STRLEN);
>grub_memcpy (vg->name, label->group_name, LDM_NAME_STRLEN);
>vg->name[LDM_NAME_STRLEN] = 0;
> @@ -261,7 +287,7 @@ make_vg (grub_disk_t disk,
>   pv->internal_id = grub_malloc (sz);
>   if (!pv->internal_id)
> {
> - grub_free (pv);
> + free_pv (pv);
>   goto fail2;
> }
>   grub_memcpy (pv->internal_id, ptr, (grub_size_t) ptr[0] + 1);
> @@ -271,7 +297,7 @@ make_vg (grub_disk_t disk,
>   if (ptr + *ptr + 1 >= vblk[i].dynamic
>   + sizeof (vblk[i].dynamic))
> {
> - grub_free (pv);
> + free_pv (pv);
>   goto fail2;
> }
>   /* ptr = name.  */
> @@ -279,23 +305,21 @@ make_vg (grub_disk_t disk,
>   if (ptr + *ptr + 1
>   >= vblk[i].dynamic + sizeof (vblk[i].dynamic))
> {
> - grub_free (pv);
> + free_pv (pv);
>   goto fail2;
> }
>   pv->id.uuidlen = *ptr;
>
>   if (grub_add (pv->id.uuidlen, 1, &sz))
> {
> - grub_free (pv->internal_id);
> - grub_free (pv);
> + free_pv (pv);
>   goto fail2;
> }
>
>   pv->id.uuid = grub_malloc (sz);
>   if (pv->id.uuid == NULL)
> {
> - grub_free (pv->internal_id);
> - grub_free (pv);
> + free_pv (pv);
>   goto fail2;
> }
>   grub_memcpy (pv->id.uuid, ptr + 1, pv->id.uuidlen);
> @@ -343,7 +367,7 @@ make_vg (grub_disk_t disk,
>   lv->segments = grub_zalloc (sizeof (*lv->segments));
>   if (!lv->segments)
> {
> - grub_free (lv);
> + free_lv (lv);
>   goto fail2;
> }
>   lv->segments->start_extent = 0;
> @@ -354,26 +378,25 @@ make_vg (grub_disk_t disk,
>  sizeof
> (*lv->segments->nodes));
>   if (!lv->segments->nodes)
> {
> - grub_free (lv);
> + free_lv (lv);
>   goto fail2;
> }
>   ptr = vblk[i].dynamic;
>   if (ptr + *ptr + 1 >= vblk[i].dynamic
>   + sizeof (vblk[i].dynamic))
> {
> - grub_free (lv);
> + free_lv (lv);
>   goto fail2;
> }
>   if (grub_add (ptr[0], 2, &sz))
> {
> - grub_free (lv->segments);
> - grub_free (lv);
> + free_lv (lv);
>   goto fail2;
> }
>   lv->internal_id = grub_malloc (sz);
>   if (!lv->internal_id)
> {
> - grub_free (lv);
> + free_lv (lv);
>   goto fail2;
> }
>   grub_memcpy (lv->internal_id, ptr, ptr[0] + 1);
> @@ -383,20 +406,18 @@ make_vg (grub_disk_t disk,
>   if (ptr + *ptr + 1 >= vblk[i].dynamic
>   + sizeof (vblk[i].dynamic))
>

Re: [PATCH 5/5] loader/xnu: Fix memory leak

[Vladimir 'phcoder' Serbinenko]

Reviewed-By : Vladimir Serbinenko

Le jeu. 27 mars 2025, 20:57, Lidong Chen via Grub-devel 
a écrit :

> In grub_xnu_load_kext_from_dir(), when the call to grub_device_open()
> failed, it simply cleaned up previously allocated memory and returned
> GRUB_ERR_NONE. However, it neglected to free ctx->newdirname which is
> allocated before the call to grub_device_open().
>
> Fixes: CID 473859
>
> Signed-off-by: Lidong Chen 
> ---
>  grub-core/loader/xnu.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/grub-core/loader/xnu.c b/grub-core/loader/xnu.c
> index 4cca55df9..80831386e 100644
> --- a/grub-core/loader/xnu.c
> +++ b/grub-core/loader/xnu.c
> @@ -1258,6 +1258,7 @@ grub_xnu_load_kext_from_dir (char *dirname, const
> char *osbundlerequired,
>grub_device_close (dev);
>  }
>grub_free (device_name);
> +  grub_free (ctx.newdirname);
>
>return GRUB_ERR_NONE;
>  }
> --
> 2.34.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 4/5] fs/btrfs: Fix memory leaks

[Vladimir 'phcoder' Serbinenko]

Reviewed-By : Vladimir Serbinenko

Le jeu. 27 mars 2025, 20:57, Lidong Chen via Grub-devel 
a écrit :

> Fix memory leaks in grub_btrfs_extent_read() and
> grub_btrfs_dir().
>
> Fixes: CID 473842
> Fixes: CID 473871
>
> Signed-off-by: Lidong Chen 
> ---
>  grub-core/fs/btrfs.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
> index 9c1e925c9..7bf8d922f 100644
> --- a/grub-core/fs/btrfs.c
> +++ b/grub-core/fs/btrfs.c
> @@ -1538,7 +1538,10 @@ grub_btrfs_extent_read (struct grub_btrfs_data
> *data,
>   err = lower_bound (data, &key_in, &key_out, tree,
>  &elemaddr, &elemsize, &desc, 0);
>   if (err)
> -   return -1;
> +   {
> + grub_free (desc.data);
> + return -1;
> +   }
>   if (key_out.object_id != ino
>   || key_out.type != GRUB_BTRFS_ITEM_TYPE_EXTENT_ITEM)
> {
> @@ -2115,6 +2118,7 @@ grub_btrfs_dir (grub_device_t device, const char
> *path,
>if (err)
>  {
>grub_btrfs_unmount (data);
> +  grub_free (desc.data);
>return err;
>  }
>if (key_out.type != GRUB_BTRFS_ITEM_TYPE_DIR_ITEM
> --
> 2.34.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 2/5] lib/reloacator: Fix memory leaks

[Vladimir 'phcoder' Serbinenko]

Reviewed-By : Vladimir Serbinenko

Le jeu. 27 mars 2025, 20:57, Lidong Chen via Grub-devel 
a écrit :

> Fix memory leaks in grub_relocator_alloc_chunk_align().
>
> Fixes: CID 473844
>
> Signed-off-by: Lidong Chen 
> ---
>  grub-core/lib/relocator.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/lib/relocator.c b/grub-core/lib/relocator.c
> index e0478ae5b..3306a1bb7 100644
> --- a/grub-core/lib/relocator.c
> +++ b/grub-core/lib/relocator.c
> @@ -1440,6 +1440,7 @@ grub_relocator_alloc_chunk_align (struct
> grub_relocator *rel,
>   break;
> }
>
> +  grub_free (ctx.chunk);
>return grub_error (GRUB_ERR_OUT_OF_MEMORY, N_("out of memory"));
>  }
>while (0);
> @@ -1456,7 +1457,10 @@ grub_relocator_alloc_chunk_align (struct
> grub_relocator *rel,
>  grub_mmap_iterate (grub_relocator_alloc_chunk_align_iter, &ctx);
>  #endif
>  if (!ctx.found)
> -  return grub_error (GRUB_ERR_BAD_OS, "couldn't find suitable memory
> target");
> +  {
> +   grub_free (ctx.chunk);
> +   return grub_error (GRUB_ERR_BAD_OS, "couldn't find suitable memory
> target");
> +  }
>}
>while (1)
>  {
> --
> 2.34.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 3/3] blsuki: Add uki command to load Unified Kernel Image entries

[Vladimir 'phcoder' Serbinenko]

>
>
>
> +#ifdef GRUB_MACHINE_EFI
> +#include 
> +#include 
> +#include 
> +#endif
> +
>
Can UKI work without EFI? I think of scenario of putting e.g. EFI disk into
coreboot or BIOS machine.

>  GRUB_MOD_LICENSE ("GPLv3+");
>
>  #define GRUB_BLS_CONFIG_PATH "/loader/entries/"
> +#define GRUB_UKI_CONFIG_PATH "/EFI/Linux"
> +
> +#define GRUB_BLS_CMD 1
> +#define GRUB_UKI_CMD 2
> +
> +static int cmd_type = 0;
>
Can we make this into an enum?

>
>
>
> +  if (pe->optional_header.magic != GRUB_PE32_NATIVE_MAGIC)
> +{
> +  err = grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, "non-native image
> not supported");
>
Maybe it's a bad kernel and not not implemented yet? Later indicates that
sick a config is valid, just not supported yet. Is it so?

> +
> +static char *
> +uki_read_osrel (char *content, grub_off_t *pos, char **key_ret, char
> **val_ret)
> +{
> +  char *line;
> +  char *value;
> +  grub_size_t linelen;
> +
> + skip:
> +  line = content + *pos;
> +  if (*line == '\0')
> +return NULL;
> +
> +  linelen = 0;
> +  while (line[linelen] != '\0' && !grub_strchr ("\n\r", line[linelen]))
>
While I recognize the elegance of strchr, we don't use this trick in the
code and it makes it more difficult to read. Can you use 2 comparisons
instead?

> +linelen++;
> +
> +  /* Move pos to the next line */
> +  *pos += linelen;
> +  if (content[*pos] != '\0')
> +(*pos)++;
> +
> +  /* Skip empty line */
> +  if (linelen == 0)
> +goto skip;
> +
> +  line[linelen] = '\0';
> +
> +  /* Remove leading white space */
> +  while (grub_strchr (" \t", *line))
>
Ditto

> +{
> +  line++;
> +  linelen--;
> +}
> +
> +  /* Remove trailing whitespace */
> +  while (linelen > 0 && grub_strchr ("=", line[linelen - 1]))
> +linelen--;
>
Comment doesn't match what really happens here. Also strchr with single
character string makes no sense.

> +  line[linelen] = '\0';
> +
> +  if (*line == '#')
> +goto skip;
> +
> +  /* Split key/value */
> +  value = line;
> +  while (*value != '\0' && !grub_strchr ("=", *value))
> +value++;
>
Ditto

> +  if (*value == '\0')
> +goto skip;
> +  *value = '\0';
> +  value++;
> +  while (*value != '\0' && grub_strchr ("=", *value))
> +value++;
>
Ditto

>
> +  if (grub_mul (argc + 1, sizeof (char *), &size))
> +{
> +  grub_error (GRUB_ERR_OUT_OF_RANGE, N_("overflow detected creating
> argv list"));
>
Not worth translating. Generally the code which is only to guard against
malicious input is not worth translating

+  goto finish;
> +}
> +  argv = grub_malloc (size);
> +  if (argv == NULL)
> +{
> +  grub_error (GRUB_ERR_OUT_OF_MEMORY, "failed to allocate argv list");
>
Grub_malloc already sets err no.

> +  goto finish;
> +}
> +  argv[0] = title;
> +  argv[argc] = NULL;
> +
> +  src = grub_xasprintf ("insmod chain\n"
>
Why do you need insmod? Didn't automatic insmod work?

+   "chainloader (%s)%s/%s%s%s\n",
> +   entry->devid, entry->dirname,
> +   entry->filename, options ? " " : "", options ?
> options : "");
>
Can we have a Linux variant for non-EFI?

>
>
>/*
> * If we aren't able to find BLS entries in the directory given by
> info->dirname,
> * we can fallback to the default location "/boot/loader/entries/" and
> see if we
> -   * can find the files there.
> +   * can find the files there. If we can't find UKI entries, fallback to
> +   * "/boot/efi/EFI/Linux".
> */
>
What's the purpose of fallback? It's not what user/script has requested. It
needs to be at very least disableable

>
>
> +   }
> +  else if (cmd_type == GRUB_UKI_CMD)
> +   {
> +#ifdef GRUB_MACHINE_EFI
> + grub_efi_loaded_image_t *image;
> + image = grub_efi_get_loaded_image (grub_efi_image_handle);
> + devid = grub_efidisk_get_device_name (image->device_handle);
> +#endif
>
This uses grub image location. What about a scenario when booted from
external drive and I want to boot into install on primary disk?

>
> +static grub_err_t
> +grub_cmd_blscfg (grub_extcmd_context_t ctxt, int argc __attribute__
> ((unused)),
> +char **args __attribute__ ((unused)))
> +{
> +  cmd_type = GRUB_BLS_CMD;
> +  return blsuki_cmd (ctxt);
>
Do we really need a static variable? Maybe a parameter is more appropriate?
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 2/3] blsuki: Check for mounted /boot in emu

[Vladimir 'phcoder' Serbinenko]

Le mar. 25 mars 2025, 10:15, Alec Brown  a écrit :

> Irritatingly, BLS defines paths relatives to the mountpoint of the
> filesystem which contains its snippets, not / or any other fixed
> location. So grub2-emu needs to know whether /boot is a separate
> filesystem from / and conditionally prepend a path.
>
> Signed-off-by: Robbie Harwood 
> Signed-off-by: Alec Brown 
> ---
>  grub-core/Makefile.core.def |  4 +++
>  grub-core/commands/blsuki.c | 54 -
>  grub-core/osdep/linux/getroot.c |  8 +
>  grub-core/osdep/unix/getroot.c  | 10 ++
>  include/grub/emu/misc.h |  2 +-
>  5 files changed, 70 insertions(+), 8 deletions(-)
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index f3b776c0a..9a0e7bc55 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -367,6 +367,10 @@ kernel = {
>emu = kern/emu/cache_s.S;
>emu = kern/emu/hostdisk.c;
>emu = osdep/unix/hostdisk.c;
> +  emu = osdep/relpath.c;
> +  emu = osdep/getroot.c;
> +  emu = osdep/unix/getroot.c;
> +  emu = osdep/devmapper/getroot.c;
>emu = osdep/exec.c;
>extra_dist = osdep/unix/exec.c;
>emu = osdep/devmapper/hostdisk.c;
> diff --git a/grub-core/commands/blsuki.c b/grub-core/commands/blsuki.c
> index 0f77fb568..12a9a1ed1 100644
> --- a/grub-core/commands/blsuki.c
> +++ b/grub-core/commands/blsuki.c
> @@ -32,6 +32,13 @@
>  #include 
>  #include 
>
> +#ifdef GRUB_MACHINE_EMU
> +#include 
> +#define GRUB_BOOT_DEVICE "/boot"
> +#else
> +#define GRUB_BOOT_DEVICE ""
> +#endif
> +
>  GRUB_MOD_LICENSE ("GPLv3+");
>
>  #define GRUB_BLS_CONFIG_PATH "/loader/entries/"
> @@ -53,8 +60,40 @@ struct keyval
>
>  static grub_blsuki_entry_t *entries = NULL;
>
> +/*
> + * Cache probing in blsuki_update_boot_device(). Used for linux entry
> also.
> + */
> +static int separate_boot = -1;
>

On non-emu it's an unused static. It might trigger a warning. I'd prefer
this to be inside ifdef.

+
>  #define FOR_BLSUKI_ENTRIES(var) FOR_LIST_ELEMENTS (var, entries)
>
> +/*
> + * BLS appears to make paths relative to the filesystem that snippets are
> + * on, not /.  Attempt to cope.
> + */
> +static char *blsuki_update_boot_device (char *tmp)
> +{
> +#ifdef GRUB_MACHINE_EMU
> +  char *ret;
> +
> +  if (separate_boot != -1)
> +goto probed;
> +
> +  separate_boot = 0;
> +
> +  ret = grub_make_system_path_relative_to_its_root (GRUB_BOOT_DEVICE);
> +
> +  if (ret != NULL)
> +separate_boot = 1;
>
Are you sure that != NULL is the right check? It looks like it should be
strcmp with "/". How do you get a NULL here? Shouldn't happen if the path
exists.

> +
> + probed:
> +  if (!separate_boot)
> +return grub_stpcpy (tmp, " ");
> +#endif
> +
> +  return grub_stpcpy (tmp, " " GRUB_BOOT_DEVICE);
> +}
> +
>  static grub_err_t
>  blsuki_add_keyval (grub_blsuki_entry_t *entry, char *key, char *val)
>  {
> @@ -645,7 +684,7 @@ bls_create_entry (grub_blsuki_entry_t *entry)
>
>for (i = 0; early_initrds != NULL && early_initrds[i] != NULL; i++)
> {
> - if (grub_add (initrd_size, sizeof (" "), &initrd_size) ||
> + if (grub_add (initrd_size, sizeof (" " GRUB_BOOT_DEVICE),
> &initrd_size) ||
>   grub_add (initrd_size, grub_strlen (initrd_prefix),
> &initrd_size) ||
>   grub_add (initrd_size, grub_strlen (early_initrds[i]),
> &initrd_size) ||
>   grub_add (initrd_size, 1, &initrd_size))
> @@ -657,7 +696,7 @@ bls_create_entry (grub_blsuki_entry_t *entry)
>
>for (i = 0; initrds != NULL && initrds[i] != NULL; i++)
> {
> - if (grub_add (initrd_size, sizeof (" "), &initrd_size) ||
> + if (grub_add (initrd_size, sizeof (" " GRUB_BOOT_DEVICE),
> &initrd_size) ||
>   grub_add (initrd_size, grub_strlen (initrds[i]),
> &initrd_size) ||
>   grub_add (initrd_size, 1, &initrd_size))
> {
> @@ -683,7 +722,7 @@ bls_create_entry (grub_blsuki_entry_t *entry)
>for (i = 0; early_initrds != NULL && early_initrds[i] != NULL; i++)
> {
>   grub_dprintf ("blsuki", "adding early initrd %s\n",
> early_initrds[i]);
> - tmp = grub_stpcpy (tmp, " ");
> + tmp = blsuki_update_boot_device (tmp);
>   tmp = grub_stpcpy (tmp, initrd_prefix);
>   tmp = grub_stpcpy (tmp, early_initrds[i]);
>   grub_free (early_initrds[i]);
> @@ -692,7 +731,7 @@ bls_create_entry (grub_blsuki_entry_t *entry)
>for (i = 0; initrds != NULL && initrds[i] != NULL; i++)
> {
>   grub_dprintf ("blsuki", "adding initrd %s\n", initrds[i]);
> - tmp = grub_stpcpy (tmp, " ");
> + tmp = blsuki_update_boot_device (tmp);
>   tmp = grub_stpcpy (tmp, initrds[i]);
> }
>tmp = grub_stpcpy (tmp, "\n");
> @@ -711,7 +750,7 @@ bls_create_entry (grub_blsuki_entry_t *entry)
> }
> }
>
> -  if (grub_add (sizeof ("devicetree "), grub_strlen (devicetree),
> &dt_si

Re: [PATCH v4 09/12] tests/tpm2_key_protector_test: Reset 'ret' on fail

[Vladimir 'phcoder' Serbinenko]

Is there a risk here of missing the failures? It's common that no one looks
at the output unless it causes a failed build on some CI/CD

Le ven. 21 mars 2025, 11:01, Gary Lin via Grub-devel  a
écrit :

> Reset 'ret' to 0 when a test case fails so that the other test cases
> could continue.
>
> Signed-off-by: Gary Lin 
> ---
>  tests/tpm2_key_protector_test.in | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/tests/tpm2_key_protector_test.in b/tests/
> tpm2_key_protector_test.in
> index 07477ba2a..0d1115e02 100644
> --- a/tests/tpm2_key_protector_test.in
> +++ b/tests/tpm2_key_protector_test.in
> @@ -291,6 +291,7 @@ for i in "${!srktests[@]}"; do
>  echo "TPM2 [${srktests[$i]}]: PASS"
>  elif [ "${ret}" -eq 1 ]; then
>  echo "TPM2 [${srktests[$i]}]: FAIL"
> +   ret=0
>  else
> echo "Unexpected failure [${srktests[$i]}]" >&2
> exit ${ret}
> @@ -303,6 +304,7 @@ if [ "${ret}" -eq 0 ]; then
>  echo "TPM2 [NV Index]: PASS"
>  elif [ "${ret}" -eq 1 ]; then
>  echo "TPM2 [NV Index]: FAIL"
> +ret=0
>  else
>  echo "Unexpected failure [NV index]" >&2
>  exit ${ret}
> --
> 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

Re: [PATCH v3] fs/ntfs: Correct NULL Deref / Possible Infinite Loop

[Vladimir 'phcoder' Serbinenko]

Reviewed-By: Vladimir Serbinenko

Le ven. 21 mars 2025, 02:28, Andrew Hamilton  a écrit :

> A regression was introduced recently as a part of the series of
> filesystem related patches to address some CVEs found in GRUB.
>
> This issue may cause either an infinite loop at startup when
> accessing certain valid NTFS file systems, or may cause a crash
> due to a NULL pointer deference on systems where "NULL" address
> is invalid (such as may happen when calling grub-mount from
> the operating system level).
>
> Correct this issue by checking that at->attr_cur is within bounds
> inside find_attr.
>
> Fixes: https://savannah.gnu.org/bugs/?66855
>
> Co-authored-by: B Horn 
> Co-authored-by: Andrew Hamilton 
> Signed-off-by: Andrew Hamilton 
> ---
> V2 -> V3: Changed NULL check to >= at->mft->buf
>
>  grub-core/fs/ntfs.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/fs/ntfs.c b/grub-core/fs/ntfs.c
> index 960833a34..767b93c21 100644
> --- a/grub-core/fs/ntfs.c
> +++ b/grub-core/fs/ntfs.c
> @@ -387,7 +387,8 @@ find_attr (struct grub_ntfs_attr *at, grub_uint8_t
> attr)
>  }
>at->attr_cur = at->attr_nxt;
>mft_end = at->mft->buf + (at->mft->data->mft_size << GRUB_NTFS_BLK_SHR);
> -  while (at->attr_cur < mft_end && *at->attr_cur != 0xFF)
> +  while (at->attr_cur >= at->mft->buf && at->attr_cur < mft_end
> + && *at->attr_cur != 0xFF)
>  {
>at->attr_nxt = next_attribute (at->attr_cur, at->end);
>if (*at->attr_cur == GRUB_NTFS_AT_ATTRIBUTE_LIST)
> --
> 2.39.5
>
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [RFC] Rust in GRUB

[Vladimir 'phcoder' Serbinenko]

Le sam. 22 mars 2025, 03:20, Andrew Hamilton  a écrit :

> Hello,
>
> Personally, I really like this idea.
>
> I'm not yet a Rust programmer but I am happy to learn... and perhaps
> there are others like me that would take this as an opportunity to
> learn while doing something like porting a Grub module from C to Rust
> if we had that framework in place.
>
This is more complicated than it seems. Mainly for 2 reasons:
1. For i386-pc core with part_msdos+biosdisk+ has to fit
into 31K (compressed) of an old MBR gap. Simple programs in Rust even
stripped clock in 10-50K. Idk if this can be reduced somehow.
2. ia64 has no rust AFAICT. I'm unsure what to do with it. Whether to drop
ia64 is an interesting question that would need to be discussed separately.
3. Sparc64 allocates only about 1M of heap. Idk if it's enough for Rust.
Sparc64 has more RAM than this even in the most restricted scenario but we
need to figure out MMU if we want more heap

Neither however prevents from creating new code in rust or to port some
modules to C.
New filesystem sounds like a perfect candidate for rust. Rewriting a part
map that isn't msdos (due to i386-pc) or gpt (due to ia64) is also a
possibility

>
> It seems like a nice way to hopefully eliminate or reduce certain
> kinds of bugs as well.
>
> It may also be a nice opportunity to make some common processes with
> the Rust community like perhaps using rustfmt as the coding standard
> to reduce burden on developers and maintainers to deal with formatting
> and focus on functionality.
>
Do you know how to bring them in? Already at current stage their expertise
is valuable in order to get an idiomatic Rust.

>
> I like that you have a small demo module as well in what you did, it
> shows a nice starting point for people wanting to take on a module if
> this gains traction like I hope it will.
>
> Thanks!
> Andrew
>
> On Fri, Mar 21, 2025 at 3:53 PM Vladimir 'phcoder' Serbinenko
>  wrote:
> >
> > Hello, I was playing with adding Rust embedded in GRUB. I’ve pushed
> results to 2 repos:
> > Module goes to https://github.com/phcoder/grub-rust-hello/tree/master
> > Changes in GRUB are found at https://github.com/phcoder/GRUB/tree/rust
> > Notes on implementation:
> > Only i386-pc is implemented right now but it’s not a technical limit,
> just others are not implemented yet.
> > I changed GRUB to use ET_DYN (.so) binaries as modules instead of ET_REL
> (.o).
> > I disabled mregparm=3. -Z regparm=3 in Rust generally works but the
> calls to memcpy() still uses regparm=0 calling convention. Perhaps it’s a
> bug on Rust side, perhaps we need an adapter on our side.
> > It’s compiled with panic=abort. Unwinding panics require
> rust_eh_personality that isn’t implemented yet.
> > src/lib.rs is an example of hello world and grub_lib.rs is a grub-rust
> adapter. Ideally they should be in separate crates
> > Every module now pulls in rust runtime. Idk how to switch to a shared
> runtime
> > Consider it more an experiment and request for comments than a working
> product. I would be interested to hear any comments. Especially it’s
> interesting to hear from Rust folks as to how to make it more idiomatic
> Rust.
> >
> > ___
> > 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
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[RFC] Rust in GRUB

[Vladimir 'phcoder' Serbinenko]

Hello, I was playing with adding Rust embedded in GRUB. I’ve pushed results
to 2 repos:
Module goes to https://github.com/phcoder/grub-rust-hello/tree/master
Changes in GRUB are found at https://github.com/phcoder/GRUB/tree/rust
Notes on implementation:
Only i386-pc is implemented right now but it’s not a technical limit, just
others are not implemented yet.
I changed GRUB to use ET_DYN (.so) binaries as modules instead of ET_REL
(.o).
I disabled mregparm=3. -Z regparm=3 in Rust generally works but the calls
to memcpy() still uses regparm=0 calling convention. Perhaps it’s a bug on
Rust side, perhaps we need an adapter on our side.
It’s compiled with panic=abort. Unwinding panics require
rust_eh_personality that isn’t implemented yet.
src/lib.rs is an example of hello world and grub_lib.rs is a grub-rust
adapter. Ideally they should be in separate crates
Every module now pulls in rust runtime. Idk how to switch to a shared
runtime
Consider it more an experiment and request for comments than a working
product. I would be interested to hear any comments. Especially it’s
interesting to hear from Rust folks as to how to make it more idiomatic
Rust.
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2] fs/ntfs: Check at->attr_cur after calling next_attribute()

[Vladimir 'phcoder' Serbinenko]

Le ven. 21 mars 2025, 01:54, Andrew Hamilton  a écrit :

> A regression was introduced recently as a part of the series of
> filesystem related patches to address some CVEs found in GRUB.
>
> This issue may cause either an infinite loop at startup when
> accessing certain valid NTFS file systems, or may cause a crash
> due to a NULL pointer deference on systems where "NULL" address
> is invalid (such as may happen when calling grub-mount from
> the operating system level).
>
> Correct this issue by checking that at->attr_cur != NULL inside
> find_attr.
>
> Fixes: https://savannah.gnu.org/bugs/?66855
>
> Co-authored-by: B Horn 
> Co-authored-by: Andrew Hamilton 
> Signed-off-by: Andrew Hamilton 
> ---
>  grub-core/fs/ntfs.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/fs/ntfs.c b/grub-core/fs/ntfs.c
> index 960833a34..a29e10401 100644
> --- a/grub-core/fs/ntfs.c
> +++ b/grub-core/fs/ntfs.c
> @@ -387,7 +387,8 @@ find_attr (struct grub_ntfs_attr *at, grub_uint8_t
> attr)
>  }
>at->attr_cur = at->attr_nxt;
>mft_end = at->mft->buf + (at->mft->data->mft_size << GRUB_NTFS_BLK_SHR);
> -  while (at->attr_cur < mft_end && *at->attr_cur != 0xFF)
> +  while (at->attr_cur != NULL && at->attr_cur < mft_end
> + && *at->attr_cur != 0xFF)
>
Why not while (at->attr_cur >= at->mft->buf && at->attr_cur < mft_end &&
... ?

>  {
>at->attr_nxt = next_attribute (at->attr_cur, at->end);
>if (*at->attr_cur == GRUB_NTFS_AT_ATTRIBUTE_LIST)
> --
> 2.39.5
>
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] fs/zfs: Fix a number of memory leaks in ZFS code

[Vladimir 'phcoder' Serbinenko]

LGTM.
Reviewed-By: Vladimir Serbinenko

Le lun. 10 mars 2025, 19:25, Stuart Hayes  a
écrit :

> Without this fix, grub failed to boot linux with "out of memory" after
> trying to run a "search --fs-uuid..." on a system that has 7 ZFS pools
> across about 80 drives.
>
> Signed-off-by: Stuart Hayes 
> ---
>  grub-core/fs/zfs/zfs.c | 43 +-
>  grub-core/fs/zfs/zfsinfo.c |  5 -
>  2 files changed, 42 insertions(+), 6 deletions(-)
>
> diff --git a/grub-core/fs/zfs/zfs.c b/grub-core/fs/zfs/zfs.c
> index 376042631..bff9d0208 100644
> --- a/grub-core/fs/zfs/zfs.c
> +++ b/grub-core/fs/zfs/zfs.c
> @@ -1057,8 +1057,10 @@ check_pool_label (struct grub_zfs_data *data,
>ZIO_SET_CHECKSUM(&emptycksum, diskdesc->vdev_phys_sector << 9, 0, 0, 0);
>err = zio_checksum_verify (emptycksum, ZIO_CHECKSUM_LABEL, endian,
>  nvlist, VDEV_PHYS_SIZE);
> -  if (err)
> +  if (err) {
> +grub_free (nvlist);
>  return err;
> +  }
>
>grub_dprintf ("zfs", "check 2 passed\n");
>
> @@ -1144,8 +1146,10 @@ check_pool_label (struct grub_zfs_data *data,
>if (original)
>  data->guid = poolguid;
>
> -  if (data->guid != poolguid)
> +  if (data->guid != poolguid) {
> +grub_free (nvlist);
>  return grub_error (GRUB_ERR_BAD_FS, "another zpool");
> +  }
>
>{
>  char *nv;
> @@ -1186,9 +1190,12 @@ check_pool_label (struct grub_zfs_data *data,
> {
>   grub_dprintf("zfs","feature missing in
> check_pool_label:%s\n",name);
>   err= grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET,"
> check_pool_label missing feature '%s' for read",name);
> + grub_free(features);
> + grub_free(nvlist);
>   return err;
> }
> }
> +  grub_free(features);
>  }
>grub_dprintf ("zfs", "check 12 passed (feature flags)\n");
>grub_free (nvlist);
> @@ -2601,6 +2608,7 @@ zap_lookup (dnode_end_t * zap_dnode, const char
> *name, grub_uint64_t *val,
>return err;
>  }
>
> +  grub_free (zapbuf);
>return grub_error (GRUB_ERR_BAD_FS, "unknown ZAP type");
>  }
>
> @@ -2671,6 +2679,7 @@ zap_iterate_u64 (dnode_end_t * zap_dnode,
>grub_free (zapbuf);
>return ret;
>  }
> +  grub_free (zapbuf);
>grub_error (GRUB_ERR_BAD_FS, "unknown ZAP type");
>return 0;
>  }
> @@ -2701,6 +2710,7 @@ zap_iterate (dnode_end_t * zap_dnode,
>if (block_type == ZBT_MICRO)
>  {
>grub_error (GRUB_ERR_BAD_FS, "micro ZAP where FAT ZAP expected");
> +  grub_free (zapbuf);
>return 0;
>  }
>if (block_type == ZBT_HEADER)
> @@ -2712,6 +2722,7 @@ zap_iterate (dnode_end_t * zap_dnode,
>grub_free (zapbuf);
>return ret;
>  }
> +  grub_free (zapbuf);
>grub_error (GRUB_ERR_BAD_FS, "unknown ZAP type");
>return 0;
>  }
> @@ -2785,6 +2796,9 @@ dnode_get (dnode_end_t * mdn, grub_uint64_t objnum,
> grub_uint8_t type,
>  }
>
>grub_memmove (&(buf->dn), (dnode_phys_t *) dnbuf + idx, DNODE_SIZE);
> +  if (data->dnode_buf == 0)
> + /* dnbuf not used anymore if data->dnode_mdn malloc failed */
> + grub_free (dnbuf);
>buf->endian = endian;
>if (type && buf->dn.dn_type != type)
>  return grub_error(GRUB_ERR_BAD_FS, "incorrect dnode type");
> @@ -3436,6 +3450,8 @@ dnode_get_fullpath (const char *fullpath, struct
> subvolume *subvol,
>if (err)
> {
>   grub_dprintf ("zfs", "failed here\n");
> + grub_free (fsname);
> + grub_free (snapname);
>   return err;
> }
>
> @@ -3472,8 +3488,11 @@ dnode_get_fullpath (const char *fullpath, struct
> subvolume *subvol,
>if (!err)
> err = dnode_get (&(data->mos), headobj, 0,
>  &subvol->mdn, data);
> -  if (!err && subvol->mdn.dn.dn_type != DMU_OT_DSL_DATASET &&
> subvol->mdn.dn.dn_bonustype != DMU_OT_DSL_DATASET)
> +  if (!err && subvol->mdn.dn.dn_type != DMU_OT_DSL_DATASET &&
> subvol->mdn.dn.dn_bonustype != DMU_OT_DSL_DATASET) {
> +   grub_free (fsname);
> +   grub_free (snapname);
> return grub_error(GRUB_ERR_BAD_FS, "incorrect dataset dnode type");
> +  }
>
>if (err)
> {
> @@ -3952,6 +3971,7 @@ grub_zfs_open (struct grub_file *file, const char
> *fsfilename)
>  {
>void *sahdrp;
>int hdrsize;
> +  bool free_sahdrp = false;
>
>if (data->dnode.dn.dn_bonuslen != 0)
> {
> @@ -3964,6 +3984,7 @@ grub_zfs_open (struct grub_file *file, const char
> *fsfilename)
>   err = zio_read (bp, data->dnode.endian, &sahdrp, NULL, data);
>   if (err)
> return err;
> + free_sahdrp = true;
> }
>else
> {
> @@ -3972,6 +3993,8 @@ grub_zfs_open (struct grub_file *file, const char
> *fsfilename)
>
>hdrsize = SA_HDR_SIZE (((sa_hdr_phys_t *) sahdrp));
>file->size = grub_zfs_to_cpu64 (grub_get_unaligned64 ((char *)
> sahdrp + hdrsize + SA_SI

Re: [PATCH] bsd: Fix type passed for the kernel

[Vladimir 'phcoder' Serbinenko]

Le mar. 4 mars 2025, 16:25, Daniel Kiper  a écrit :

> On Mon, Mar 03, 2025 at 12:04:31AM +0300, Vladimir Serbinenko wrote:
> > FreeBSD loader always passes "elf kernel". -CURRENT kernel accepts only
>
> What is "-CURRENT"?
>
Basically HEAD/master in FreeBSD world.

>
> > "elf kernel", older kernel accepts either.
>
> You repeat "elf kernel" twice. I think something is off here...
>
No, it's correct. We pass elf64 kernel but FreeBSD passes and across only
elf kernel

>
> > Tested on FreeBSD and DragonFlyBSD
> >
> > Reference:
> https://cgit.freebsd.org/src/commit/?id=b72ae900d4348118829fe04abdc11b620930c30f
> >
> > Signed-off-by: Vladimir Serbinenko 
>
> Daniel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] fs/ntfs: Check at->attr_cur after calling next_attribute()

[Vladimir 'phcoder' Serbinenko]

Why do you remove boundary check? Maybe it's better to add the second
boundary check from below

Le ven. 28 févr. 2025, 16:11, B Horn  a écrit :

> On some NTFS volumes GRUB would enter an infinite loop when
> next_attribute() returned NULL, which can happen in normal cases when
> the end of the attribute list is reached.
> This would trigger a NULL deref, but as the null page is mapped on the
> majority of firmware, an infinite loop would occur as the while loop
> didn't make any progress.
>
> Fixing this by verifying the value of at->attr_cur on the next iteration
> of the loop, after it has been set to the result of next_attribute().
> Also removing the redundant check against mft_end as the
> next_attribute() should handle that now.
> A pointer to the end of the buffer is stored in at->end, which is
> initialized the same way as mft_end was.
>
> Fixes: https://savannah.gnu.org/bugs/index.php?66855
>
> Reported-by: Andreas Klauer 
> Signed-off-by: B Horn 
> ---
>  grub-core/fs/ntfs.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/grub-core/fs/ntfs.c b/grub-core/fs/ntfs.c
> index 960833a34..77531e627 100644
> --- a/grub-core/fs/ntfs.c
> +++ b/grub-core/fs/ntfs.c
> @@ -311,8 +311,6 @@ free_attr (struct grub_ntfs_attr *at)
>  static grub_uint8_t *
>  find_attr (struct grub_ntfs_attr *at, grub_uint8_t attr)
>  {
> -  grub_uint8_t *mft_end;
> -
>if (at->flags & GRUB_NTFS_AF_ALST)
>  {
>  retry:
> @@ -386,8 +384,7 @@ find_attr (struct grub_ntfs_attr *at, grub_uint8_t
> attr)
>return NULL;
>  }
>at->attr_cur = at->attr_nxt;
> -  mft_end = at->mft->buf + (at->mft->data->mft_size << GRUB_NTFS_BLK_SHR);
> -  while (at->attr_cur < mft_end && *at->attr_cur != 0xFF)
> +  while (at->attr_cur && *at->attr_cur != 0xFF)
>  {
>at->attr_nxt = next_attribute (at->attr_cur, at->end);
>if (*at->attr_cur == GRUB_NTFS_AT_ATTRIBUTE_LIST)
> --
> 2.48.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 v1 06/21] crypto: move storage for grub_crypto_pk_* to crypto.c

[Vladimir 'phcoder' Serbinenko]

Reviewed-By: Vladimir Serbinenko 

On Wed, Dec 18, 2024 at 5:59 PM Sudhakar Kuppusamy
 wrote:
>
> From: Daniel Axtens 
>
> The way gcry_rsa and friends (the asymmetric ciphers) are loaded for the
> pgp module is a bit quirky.
>
> include/grub/crypto.h contains:
>   extern struct gcry_pk_spec *grub_crypto_pk_rsa;
>
> commands/pgp.c contains the actual storage:
>   struct gcry_pk_spec *grub_crypto_pk_rsa;
>
> And the module itself saves to the storage in pgp.c:
>   GRUB_MOD_INIT(gcry_rsa)
>   {
> grub_crypto_pk_rsa = &_gcry_pubkey_spec_rsa;
>   }
>
> This is annoying: gcry_rsa now has a dependency on pgp!
>
> We want to be able to bring in gcry_rsa without bringing in PGP,
> so move the storage to crypto.c.
>
> Previously, gcry_rsa depended on pgp and mpi. Now it depends on
> crypto and mpi. As pgp depends on crypto, this doesn't add any new
> module dependencies using the PGP verfier.
>
> [FWIW, the story is different for the symmetric ciphers. cryptodisk
> and friends (zfs encryption etc) use grub_crypto_lookup_cipher_by_name()
> to get a cipher handle. That depends on grub_ciphers being populated
> by people calling grub_cipher_register. import_gcry.py ensures that the
> symmetric ciphers call it.]
>
> Signed-off-by: Daniel Axtens 
> Signed-off-by: Sudhakar Kuppusamy 
> ---
>  grub-core/commands/pgp.c | 4 
>  grub-core/lib/crypto.c   | 4 
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/grub-core/commands/pgp.c b/grub-core/commands/pgp.c
> index b084dc9a2..a45c2213c 100644
> --- a/grub-core/commands/pgp.c
> +++ b/grub-core/commands/pgp.c
> @@ -147,10 +147,6 @@ const char *hashes[] = {
>[0x0b] = "sha224"
>  };
>
> -struct gcry_pk_spec *grub_crypto_pk_dsa;
> -struct gcry_pk_spec *grub_crypto_pk_ecdsa;
> -struct gcry_pk_spec *grub_crypto_pk_rsa;
> -
>  static int
>  dsa_pad (gcry_mpi_t *hmpi, grub_uint8_t *hval,
>  const gcry_md_spec_t *hash, struct grub_public_subkey *sk);
> diff --git a/grub-core/lib/crypto.c b/grub-core/lib/crypto.c
> index 396f76410..d53ddbe2c 100644
> --- a/grub-core/lib/crypto.c
> +++ b/grub-core/lib/crypto.c
> @@ -121,6 +121,10 @@ grub_md_unregister (gcry_md_spec_t *cipher)
>}
>  }
>
> +struct gcry_pk_spec *grub_crypto_pk_dsa;
> +struct gcry_pk_spec *grub_crypto_pk_ecdsa;
> +struct gcry_pk_spec *grub_crypto_pk_rsa;
> +
>  void
>  grub_crypto_hash (const gcry_md_spec_t *hash, void *out, const void *in,
>       grub_size_t inlen)
> --
> 2.43.5
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



-- 
Regards
Vladimir 'phcoder' Serbinenko

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v1 05/21] pgp: factor out rsa_pad

[Vladimir 'phcoder' Serbinenko]

ub_size_t tlen, emlen, fflen;
> +  grub_uint8_t *em, *emptr;
> +  unsigned nbits = gcry_mpi_get_nbits (mod);
> +  int ret;
> +  tlen = hash->mdlen + hash->asnlen;
> +  emlen = (nbits + 7) / 8;
> +  if (emlen < tlen + 11)
> +return GPG_ERR_TOO_SHORT;
> +
> +  em = grub_malloc (emlen);
> +  if (!em)
> +return 1;
> +
> +  em[0] = 0x00;
> +  em[1] = 0x01;
> +  fflen = emlen - tlen - 3;
> +  for (emptr = em + 2; emptr < em + 2 + fflen; emptr++)
> +*emptr = 0xff;
> +  *emptr++ = 0x00;
> +  grub_memcpy (emptr, hash->asnoid, hash->asnlen);
> +  emptr += hash->asnlen;
> +  grub_memcpy (emptr, hval, hash->mdlen);
> +
> +  ret = gcry_mpi_scan (hmpi, GCRYMPI_FMT_USG, em, emlen, 0);
> +  grub_free (em);
> +  return ret;
> +}
> diff --git a/include/grub/pkcs1_v15.h b/include/grub/pkcs1_v15.h
> new file mode 100644
> index 0..5c338c84a
> --- /dev/null
> +++ b/include/grub/pkcs1_v15.h
> @@ -0,0 +1,27 @@
> +/*
> + *  GRUB  --  GRand Unified Bootloader
> + *  Copyright (C) 2013  Free Software Foundation, Inc.
> + *
> + *  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 <http://www.gnu.org/licenses/>.
> + */
> +
> +/*
> + * Given a hash value 'hval', of hash specification 'hash', perform
> + * the EMSA-PKCS1-v1_5 padding suitable for a key with modulus 'mod'
> + * (See RFC 8017 s 9.2)
> + */
> +gcry_err_code_t
> +grub_crypto_rsa_pad (gcry_mpi_t * hmpi, grub_uint8_t * hval,
> +const gcry_md_spec_t * hash, gcry_mpi_t mod);
> +
> --
> 2.43.5
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



-- 
Regards
Vladimir 'phcoder' Serbinenko

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v1 04/21] dl: provide a fake grub_dl_set_persistent for the emu target

[Vladimir 'phcoder' Serbinenko]

grub-emu has 2 modes: full with all modules compiled-in and lite with
actual module loading (mostly useful for testing module loading
itself.
So just adding if (mod) ... is going to fix all cases and avoids ifdef

On Wed, Dec 18, 2024 at 5:58 PM Sudhakar Kuppusamy
 wrote:
>
> From: Daniel Axtens 
>
> Trying to start grub-emu with a module that calls grub_dl_set_persistent
> will crash because grub-emu fakes modules and passes NULL to the module
> init function.
>
> Provide an empty function for the emu case.
>
> Fixes: ee7808e2197c (dl: Add support for persistent modules)
> Signed-off-by: Daniel Axtens 
> Signed-off-by: Sudhakar Kuppusamy 
> ---
>  include/grub/dl.h | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/include/grub/dl.h b/include/grub/dl.h
> index 750fc8d3d..fb4476797 100644
> --- a/include/grub/dl.h
> +++ b/include/grub/dl.h
> @@ -242,11 +242,22 @@ grub_dl_get (const char *name)
>return 0;
>  }
>
> +#ifdef GRUB_MACHINE_EMU
> +/*
> + * Under grub-emu, modules are faked and NULL is passed to GRUB_MOD_INIT.
> + * So we fake this out to avoid a NULL deref.
> + */
> +static inline void
> +grub_dl_set_persistent (grub_dl_t mod __attribute__((unused)))
> +{
> +}
> +#else
>  static inline void
>  grub_dl_set_persistent (grub_dl_t mod)
>  {
>mod->persistent = 1;
>  }
> +#endif
>
>  static inline int
>  grub_dl_is_persistent (grub_dl_t mod)
> --
> 2.43.5
>
>
> _______
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



-- 
Regards
Vladimir 'phcoder' Serbinenko

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v1 03/21] docs/grub: Document signing grub with an appended signature

[Vladimir 'phcoder' Serbinenko]

May we instead invoke sign-file from grub-mkimage as to spare the user
the hassle?

On Wed, Dec 18, 2024 at 5:58 PM Sudhakar Kuppusamy
 wrote:
>
> From: Daniel Axtens 
>
> Signing grub for firmware that verifies an appended signature is a
> bit fiddly. I don't want people to have to figure it out from scratch
> so document it here.
>
> Signed-off-by: Daniel Axtens 
> Signed-off-by: Sudhakar Kuppusamy 
> ---
>  docs/grub.texi | 42 ++
>  1 file changed, 42 insertions(+)
>
> diff --git a/docs/grub.texi b/docs/grub.texi
> index c07d5d0dc..6e483298d 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -9135,6 +9135,48 @@ image works under UEFI secure boot and can maintain 
> the secure-boot chain. It
>  will also be necessary to enrol the public key used into a relevant firmware
>  key database.
>
> +@section Signing GRUB with an appended signature
> +
> +The @file{core.img} itself can be signed with a Linux kernel module-style
> +appended signature.
> +
> +To support IEEE1275 platforms where the boot image is often loaded directly
> +from a disk partition rather than from a file system, the @file{core.img}
> +can specify the size and location of the appended signature with an ELF
> +note added by @command{grub-install}.
> +
> +An image can be signed this way using the @command{sign-file} command from
> +the Linux kernel:
> +
> +@example
> +@group
> +# grub.key is your private key and certificate.der is your public key
> +
> +# Determine the size of the appended signature. It depends on the signing
> +# certificate and the hash algorithm
> +touch empty
> +sign-file SHA256 grub.key certificate.der empty empty.sig
> +SIG_SIZE=`stat -c '%s' empty.sig`
> +rm empty empty.sig
> +
> +# Build a grub image with $SIG_SIZE reserved for the signature
> +grub-install --appended-signature-size $SIG_SIZE --modules="..." ...
> +
> +# Replace the reserved size with a signature:
> +# cut off the last $SIG_SIZE bytes with truncate's minus modifier
> +truncate -s -$SIG_SIZE /boot/grub/powerpc-ieee1275/core.elf core.elf.unsigned
> +# sign the trimmed file with an appended signature, restoring the correct 
> size
> +sign-file SHA256 grub.key certificate.der core.elf.unsigned core.elf.signed
> +
> +# Don't forget to install the signed image as required
> +# (e.g. on powerpc-ieee1275, to the PReP partition)
> +@end group
> +@end example
> +
> +As with UEFI secure boot, it is necessary to build in the required modules,
> +or sign them separately.
> +
> +
>  @node Platform limitations
>  @chapter Platform limitations
>
> --
> 2.43.5
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



-- 
Regards
Vladimir 'phcoder' Serbinenko

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v1 01/21] powerpc-ieee1275: Add support for signing grub with an appended signature

[Vladimir 'phcoder' Serbinenko]

free (arguments->memdisk);
> @@ -330,6 +340,7 @@ main (int argc, char *argv[])
>arguments.memdisk, arguments.pubkeys,
>arguments.npubkeys, arguments.config,
>arguments.image_target, arguments.note,
> +  arguments.appsig_size,
>arguments.comp, arguments.dtb,
>arguments.sbat, arguments.disable_shim_lock,
>arguments.disable_cli);
> diff --git a/util/grub-mkimagexx.c b/util/grub-mkimagexx.c
> index 448862b2e..6fe348e5b 100644
> --- a/util/grub-mkimagexx.c
> +++ b/util/grub-mkimagexx.c
> @@ -115,6 +115,14 @@ struct grub_sbat_note {
>char name[ALIGN_UP(sizeof(GRUB_SBAT_NOTE_NAME), 4)];
>  };
>
> +#define GRUB_APPENDED_SIGNATURE_NOTE_NAME "Appended-Signature"
> +#define GRUB_APPENDED_SIGNATURE_NOTE_TYPE 0x41536967 /* "ASig" */
> +struct grub_appended_signature_note
> +{
> +  Elf32_Nhdr header;
> +  char name[ALIGN_UP (sizeof (GRUB_APPENDED_SIGNATURE_NOTE_NAME), 4)];
> +};
> +
>  static int
>  is_relocatable (const struct grub_install_image_target_desc *image_target)
>  {
> @@ -216,7 +224,7 @@ grub_arm_reloc_jump24 (grub_uint32_t *target, Elf32_Addr 
> sym_addr)
>
>  void
>  SUFFIX (grub_mkimage_generate_elf) (const struct 
> grub_install_image_target_desc *image_target,
> -   int note, char *sbat, char **core_img, 
> size_t *core_size,
> +   int note, char *sbat, size_t appsig_size, 
> char **core_img, size_t *core_size,
> Elf_Addr target_addr,
> struct grub_mkimage_layout *layout)
>  {
> @@ -237,6 +245,12 @@ SUFFIX (grub_mkimage_generate_elf) (const struct 
> grub_install_image_target_desc
>footer_size += ALIGN_UP (sizeof (struct grub_sbat_note) + 
> layout->sbat_size, 4);
>  }
>
> +  if (appsig_size)
> +{
> +  phnum++;
> +  footer_size += ALIGN_UP (sizeof (struct grub_appended_signature_note) 
> + appsig_size, 4);
> +}
> +
>if (image_target->id != IMAGE_LOONGSON_ELF)
>  phnum += 2;
>
> @@ -527,6 +541,28 @@ SUFFIX (grub_mkimage_generate_elf) (const struct 
> grub_install_image_target_desc
>phdr->p_filesz = grub_host_to_target32 (note_size);
>phdr->p_memsz = 0;
>phdr->p_offset = grub_host_to_target32 (header_size + program_size + 
> footer_offset);
> +  footer += note_size;
> +  footer_offset += note_size;
> +}
> +
> +  if (appsig_size)
> +{
> +  int note_size = ALIGN_UP (sizeof (struct grub_appended_signature_note) 
> + appsig_size, 4);
> +  struct grub_appended_signature_note *note_ptr = (struct 
> grub_appended_signature_note *) footer;
> +  note_ptr->header.n_namesz = grub_host_to_target32 (sizeof 
> (GRUB_APPENDED_SIGNATURE_NOTE_NAME));
> +  /* needs to sit at the end, so we round this up and sign some zero 
> padding */
> +  note_ptr->header.n_descsz = grub_host_to_target32 (ALIGN_UP 
> (appsig_size, 4));
> +  note_ptr->header.n_type = grub_host_to_target32 
> (GRUB_APPENDED_SIGNATURE_NOTE_TYPE);
> +  strcpy (note_ptr->name, GRUB_APPENDED_SIGNATURE_NOTE_NAME);
> +  phdr++;
> +  phdr->p_type = grub_host_to_target32 (PT_NOTE);
> +  phdr->p_flags = grub_host_to_target32 (PF_R);
> +  phdr->p_align = grub_host_to_target32 (image_target->voidp_sizeof);
> +  phdr->p_vaddr = 0;
> +  phdr->p_paddr = 0;
> +  phdr->p_filesz = grub_host_to_target32 (note_size);
> +  phdr->p_memsz = 0;
> +  phdr->p_offset = grub_host_to_target32 (header_size + program_size + 
> footer_offset);
>  }
>
>{
> diff --git a/util/mkimage.c b/util/mkimage.c
> index b46df2909..f5c59f563 100644
> --- a/util/mkimage.c
> +++ b/util/mkimage.c
> @@ -885,7 +885,7 @@ grub_install_generate_image (const char *dir, const char 
> *prefix,
>  char *memdisk_path, char **pubkey_paths,
>  size_t npubkeys, char *config_path,
>  const struct grub_install_image_target_desc 
> *image_target,
> -int note, grub_compression_t comp, const char 
> *dtb_path,
> +int note, size_t appsig_size, grub_compression_t 
> comp, const char *dtb_path,
>  const char *sbat_path, int disable_shim_lock,
>  int disable_cli)
>  {
> @@ -1833,10 +1833,10 @@ grub_install_generate_image (const char *dir, const 
> char *prefix,
> else
>   target_addr = image_target->link_addr;
> if (image_target->voidp_sizeof == 4)
> - grub_mkimage_generate_elf32 (image_target, note, sbat, &core_img, 
> &core_size,
> + grub_mkimage_generate_elf32 (image_target, note, sbat, appsig_size, 
> &core_img, &core_size,
>target_addr, &layout);
> else
> - grub_mkimage_generate_elf64 (image_target, note, sbat, &core_img, 
> &core_size,
> + grub_mkimage_generate_elf64 (image_target, note, sbat, appsig_size, 
> &core_img, &core_size,
>target_addr, &layout);
>}
>break;
> --
> 2.43.5
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



-- 
Regards
Vladimir 'phcoder' Serbinenko

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2] acpi: Use options enum to index command options

[Vladimir 'phcoder' Serbinenko]

Reviewed-by: Vladimir Serbinenko 

On Fri, Jan 3, 2025 at 9:13 AM Glenn Washburn
 wrote:
>
> Signed-off-by: Glenn Washburn 
> ---
> This should be a quick review.
>
> v2: Rebase to current master
>
> Glenn
> ---
> Range-diff against v1:
> 1:  fbaf2eb14231 ! 1:  8b14fcf62f88 acpi: Use options enum to index command 
> options
> @@ grub-core/commands/acpi.c
> {"exclude", 'x', 0,
>  N_("Don't load host tables specified by comma-separated list."),
>  @@ grub-core/commands/acpi.c: grub_cmd_acpi (struct grub_extcmd_context 
> *ctxt, int argc, char **args)
> -   /* RSDT consists of header and an array of 32-bit pointers. */
> -   struct grub_acpi_table_header *rsdt;
> +   grub_size_t tbl_addr_size;
> +   struct grub_acpi_table_header *table_head;
>
>  -  exclude = state[0].set ? grub_strdup (state[0].arg) : 0;
>  +  exclude = state[OPTION_EXCLUDE].set ? grub_strdup 
> (state[OPTION_EXCLUDE].arg) : 0;
>
>  grub-core/commands/acpi.c | 46 +--
>  1 file changed, 30 insertions(+), 16 deletions(-)
>
> diff --git a/grub-core/commands/acpi.c b/grub-core/commands/acpi.c
> index 77be99a5879c..429ee6f14834 100644
> --- a/grub-core/commands/acpi.c
> +++ b/grub-core/commands/acpi.c
> @@ -38,6 +38,20 @@
>
>  GRUB_MOD_LICENSE ("GPLv3+");
>
> +enum
> +  {
> +OPTION_EXCLUDE,
> +OPTION_LOAD_ONLY,
> +OPTION_V1,
> +OPTION_V2,
> +OPTION_OEMID,
> +OPTION_OEMTABLE,
> +OPTION_OEMTABLEREV,
> +OPTION_OEMTABLECREATOR,
> +OPTION_OEMTABLECREATORREV,
> +OPTION_NO_EBDA
> +  };
> +
>  static const struct grub_arg_option options[] = {
>{"exclude", 'x', 0,
> N_("Don't load host tables specified by comma-separated list."),
> @@ -497,14 +511,14 @@ grub_cmd_acpi (struct grub_extcmd_context *ctxt, int 
> argc, char **args)
>grub_size_t tbl_addr_size;
>struct grub_acpi_table_header *table_head;
>
> -  exclude = state[0].set ? grub_strdup (state[0].arg) : 0;
> +  exclude = state[OPTION_EXCLUDE].set ? grub_strdup 
> (state[OPTION_EXCLUDE].arg) : 0;
>if (exclude)
> {
>   for (ptr = exclude; *ptr; ptr++)
> *ptr = grub_tolower (*ptr);
> }
>
> -  load_only = state[1].set ? grub_strdup (state[1].arg) : 0;
> +  load_only = state[OPTION_EXCLUDE].set ? grub_strdup 
> (state[OPTION_EXCLUDE].arg) : 0;
>if (load_only)
> {
>   for (ptr = load_only; *ptr; ptr++)
> @@ -623,26 +637,26 @@ grub_cmd_acpi (struct grub_extcmd_context *ctxt, int 
> argc, char **args)
>  }
>
>/* Does user specify versions to generate? */
> -  if (state[2].set || state[3].set)
> +  if (state[OPTION_V1].set || state[OPTION_V2].set)
>  {
> -  rev1 = state[2].set;
> -  if (state[3].set)
> +  rev1 = state[OPTION_V1].set;
> +  if (state[OPTION_V2].set)
> rev2 = rev2 ? : 2;
>else
> rev2 = 0;
>  }
>
>/* Does user override root header information? */
> -  if (state[4].set)
> -grub_strncpy (root_oemid, state[4].arg, sizeof (root_oemid));
> -  if (state[5].set)
> -grub_strncpy (root_oemtable, state[5].arg, sizeof (root_oemtable));
> -  if (state[6].set)
> -root_oemrev = grub_strtoul (state[6].arg, 0, 0);
> -  if (state[7].set)
> -grub_strncpy (root_creator_id, state[7].arg, sizeof (root_creator_id));
> -  if (state[8].set)
> -root_creator_rev = grub_strtoul (state[8].arg, 0, 0);
> +  if (state[OPTION_OEMID].set)
> +grub_strncpy (root_oemid, state[OPTION_OEMID].arg, sizeof (root_oemid));
> +  if (state[OPTION_OEMTABLE].set)
> +grub_strncpy (root_oemtable, state[OPTION_OEMTABLE].arg, sizeof 
> (root_oemtable));
> +  if (state[OPTION_OEMTABLEREV].set)
> +root_oemrev = grub_strtoul (state[OPTION_OEMTABLEREV].arg, 0, 0);
> +  if (state[OPTION_OEMTABLECREATOR].set)
> +grub_strncpy (root_creator_id, state[OPTION_OEMTABLECREATOR].arg, sizeof 
> (root_creator_id));
> +  if (state[OPTION_OEMTABLECREATORREV].set)
> +root_creator_rev = grub_strtoul (state[OPTION_OEMTABLECREATORREV].arg, 
> 0, 0);
>
>/* Load user tables */
>for (i = 0; i < argc; i++)
> @@ -758,7 +772,7 @@ grub_cmd_acpi (struct grub_extcmd_context *ctxt, int 
> argc, char **args)
>acpi_tables = 0;
>
>  #if defined (__i386__) || defined (__x86_64__)
> -  if (! state[9].set)
> +  if (! state[OPTION_NO_EBDA].set)
>  {
>grub_err_t err;
>err = grub_acpi_create_ebda ();
> --
> 2.34.1
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



-- 
Regards
Vladimir 'phcoder' Serbinenko

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Mandatory install device check for PowerPC

[Vladimir 'phcoder' Serbinenko]

As discussed in another thread, this breaks installing from x86 onto
removable disk for PPC Mac which is a supported workflow

Le ven. 8 nov. 2024, 14:13, Avnish Chouhan  a écrit :

> This patch adds a check on install_device while installing grub for
> PowerPC.
> If install_device is not mentioned in grub2-install and machine is detected
> as PowerPC, the error will be thrown and it will terminates the
> grub2-install
> operation. Running grub2-install on PowerPC without the install_device may
> result in bootlist corruption. When no install device is specified, it
> attempts
> to load images from the filesystem, which leads to nvram bootlist
> corruption.
> The idea is to fail the operation and avoid creating the invalid boot
> entry.
>
> Signed-off-by: Avnish Chouhan 
> ---
>  grub-install.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/util/grub-install.c b/util/grub-install.c
> index 7dc5657..a049f53 100644
> --- a/util/grub-install.c
> +++ b/util/grub-install.c
> @@ -1289,6 +1289,17 @@ main (int argc, char *argv[])
>   is_prep = 0;
> }
> }
> +  else
> +{
> + /*
> +  * As the machine has been detected as PowerPC and not the
> PowerMac. We need to check
> +  * whether the install_device has been mentioned while
> installing. If no device has been
> +  * mentioned, we need to exit and mark it as an error as the
> install_device is required for
> +  * PowerPC installation. An installation with no device
> mentioned may lead to corruptions.
> +  */
> +   if (!install_device)
> + grub_util_error ("%s", _("install device isn't specified
> required for PowerPC"));
> +}
>  }
>
>size_t ndev = 0;
> --
> 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

Re: default entry different from timeout entry

[Vladimir 'phcoder' Serbinenko]

Le lun. 14 oct. 2024, 00:13, Samuel Thibault 
a écrit :

> Hello,
>
> For the debian installation CD, when using syslinux we can set an
> on-timeout entry which is different from the default entry. This is
> quite important because we want sighted people to be able to just press
> enter to get the sighted installer, and non-sighted people to possibly
> just have to wait before getting a self-speaking installer.
>
> Would it be ok to implement this in grub?
>
How do you inform the user about this arrangement? For sighted people there
is expectation that highlighted entry will be booted automatically and also
that highlighted entry is booted on enter. It's probably just a UI problem
though and it's just a question of correct communication.

>
> Samuel
>
> ___
> 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 v1 0/5] Fedora Rawhide BTRFS patches

[Vladimir 'phcoder' Serbinenko]

I think the entire series is bad if I understand it correctly. I ask the
same question again: are some files inaccessible with current code but
become accessible with these patches? Aka can I create a file that I can't
read with grub-fstest in the current code?
 GRUB2 follows strict design that same full file name refers to the same
file and doesn't have some hidden state. It's possible to add some state
outside of disk drivers like having an analog of relative paths or handling
it on script level but the fs drivers are definitely not the right place to
patch up the difference between mount-based unix model and full path model
used in GRUB.

Le jeu. 31 oct. 2024, 22:43, Leo Sandoval  a écrit :

> This series contains BTRFS patches taken from Fedora Rawhide [1]. Some of
> these patches have already being sent [2][3] however, as suggested
> by Daniel Kiper, to make the review easier, I took only BTRFS related
> patches
> from [1][2][3] and create the series.
>
> [1] https://src.fedoraproject.org/rpms/grub2
> [2] https://lists.gnu.org/archive/html/grub-devel/2024-10/msg00145.html
> [3] https://lists.gnu.org/archive/html/grub-devel/2024-10/msg00192.html
>
> Jeff Mahoney (1):
>   btrfs: Add ability to boot from subvolumes
>
> Michael Chang (2):
>   btrfs: export btrfs_subvol and btrfs_subvolid
>   btrfs: Allow specifying btrfs_relative_path to follow the default
> subvolume
>
> Peter Jones (2):
>   btrfs: fix a bad null check
>   btrfs: Fixup for newer compiler
>
>  grub-core/fs/btrfs.c | 629 ---
>  include/grub/btrfs.h |   1 +
>  2 files changed, 595 insertions(+), 35 deletions(-)
>
> --
> 2.46.2
>
>
> ___
> 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 22/29] btrfs: Add ability to boot from subvolumes

[Vladimir 'phcoder' Serbinenko]

Le lun. 21 oct. 2024, 06:49, Michael Chang via Grub-devel <
grub-devel@gnu.org> a écrit :

> On Fri, Oct 18, 2024 at 08:39:01PM GMT, Vladimir 'phcoder' Serbinenko
> wrote:
> > Le lun. 14 oct. 2024, 20:10, Leo Sandoval  a écrit
> :
> >
> > > From: Jeff Mahoney 
> > >
> > > This patch adds the ability to specify a different root on a btrfs
> > > filesystem too boot from other than the default one.
> > >
> > Does it make available some files that are currentl y unavailable? Do you
> > have an example?
>
> Say, if we want to boot snapshot "foo" via it's grub.cfg, the config can
> be written as:
>
>   menuentry "boot snapshot foo" {
> saved_subvol=$btrfs_subvol
> btrfs_subvol=foo
> configfile /boot/grub/grub.cfg
> btrfs_subvol=$saved_subvol
>   }
>
> In combination with relative path, the grub.cfg executed from foo
> snapshot is also set to use files from foo snapshots explicitly. rather
> than default or other sources.
>
It's not the question I asked

>
> Thanks,
> Michael
>
> >
> > >
> > > btrfs-list-snapshots  will list the subvolumes available on the
> > > filesystem.
> > >
> > > set btrfs_subvol= and set btrfs_subvolid= will specify
> > > which subvolume to use and any pathnames provided with either of those
> > > variables set will start using that root. If the subvolume or
> subvolume id
> > > doesn't exist, then an error case will result.
> > >
> > > It is possible to boot into a separate GRUB instance by exporting the
> > > variable and loading the config file from the subvolume.
> > >
> > > Signed-off-by: Jeff Mahoney 
> > > ---
> > >  grub-core/fs/btrfs.c | 554 +--
> > >  include/grub/btrfs.h |   1 +
> > >  2 files changed, 534 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
> > > index ba0c58352..f14fe9c1b 100644
> > > --- a/grub-core/fs/btrfs.c
> > > +++ b/grub-core/fs/btrfs.c
> > > @@ -38,6 +38,9 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > > +#include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -79,9 +82,11 @@ struct grub_btrfs_superblock
> > >grub_uint64_t generation;
> > >grub_uint64_t root_tree;
> > >grub_uint64_t chunk_tree;
> > > -  grub_uint8_t dummy2[0x20];
> > > +  grub_uint8_t dummy2[0x18];
> > > +  grub_uint64_t bytes_used;
> > >grub_uint64_t root_dir_objectid;
> > > -  grub_uint8_t dummy3[0x41];
> > > +  grub_uint64_t num_devices;
> > > +  grub_uint8_t dummy3[0x39];
> > >struct grub_btrfs_device this_device;
> > >char label[0x100];
> > >grub_uint8_t dummy4[0x100];
> > > @@ -121,6 +126,7 @@ struct grub_btrfs_data
> > >grub_uint64_t exttree;
> > >grub_size_t extsize;
> > >struct grub_btrfs_extent_data *extent;
> > > +  grub_uint64_t fs_tree;
> > >  };
> > >
> > >  struct grub_btrfs_chunk_item
> > > @@ -191,6 +197,14 @@ struct grub_btrfs_leaf_descriptor
> > >} *data;
> > >  };
> > >
> > > +struct grub_btrfs_root_ref
> > > +{
> > > +  grub_uint64_t dirid;
> > > +  grub_uint64_t sequence;
> > > +  grub_uint16_t name_len;
> > > +  const char name[0];
> > > +} __attribute__ ((packed));
> > > +
> > >  struct grub_btrfs_time
> > >  {
> > >grub_int64_t sec;
> > > @@ -236,6 +250,14 @@ struct grub_btrfs_extent_data
> > >
> > >  #define GRUB_BTRFS_OBJECT_ID_CHUNK 0x100
> > >
> > > +#define GRUB_BTRFS_ROOT_TREE_OBJECTID 1ULL
> > > +#define GRUB_BTRFS_FS_TREE_OBJECTID 5ULL
> > > +#define GRUB_BTRFS_ROOT_REF_KEY 156
> > > +#define GRUB_BTRFS_ROOT_ITEM_KEY 132
> > > +
> > > +static grub_uint64_t btrfs_default_subvolid = 0;
> > > +static char *btrfs_default_subvol = NULL;
> > > +
> > >  static grub_disk_addr_t superblock_sectors[] = { 64 * 2, 64 * 1024 *
> 2,
> > >256 * 1048576 * 2, 1048576ULL * 1048576ULL * 2
> > >  };
> > > @@ -1252,6 +1274,62 @@ grub_btrfs_read_logical (struct grub_btrfs_data
> > > *data, grub_disk_addr_t addr,
> > >return GRUB_ERR_NONE;
> > >  }
> > >
> > > +

Re: [PATCH] add tpcm mod in grub

[Vladimir 'phcoder' Serbinenko]

Le sam. 19 oct. 2024, 15:51, chench246  a écrit :

> From: chench246 
>
> TPCM(Trusted Platform Control Module) is a Chinese standard and is
> compatible with TPM.
>
Before I review the patch: can you explain about compatibility. Of you day
that it's compatible with TPM, why doesn't normal TPM code work?

---
>  grub-core/Makefile.core.def   |   7 ++
>  grub-core/commands/efi/tpcm.c | 163 ++
>  grub-core/commands/tpcm.c |  99 +
>  include/grub/efi/tpcm.h   |  60 +
>  include/grub/err.h|   3 +-
>  5 files changed, 331 insertions(+), 1 deletion(-)
>  create mode 100755 grub-core/commands/efi/tpcm.c
>  create mode 100755 grub-core/commands/tpcm.c
>  create mode 100644 include/grub/efi/tpcm.h
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index 063ef5dd7..f1250601b 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -2562,6 +2562,13 @@ module = {
>enable = efi;
>  };
>
> +module = {
> +  name = tpcm;
> +  common = commands/tpcm.c;
> +  efi = commands/efi/tpcm.c;
> +  enable = x86_64_efi;
> +};
> +
>  module = {
>name = tr;
>common = commands/tr.c;
> diff --git a/grub-core/commands/efi/tpcm.c b/grub-core/commands/efi/tpcm.c
> new file mode 100755
> index 0..bc97e800c
> --- /dev/null
> +++ b/grub-core/commands/efi/tpcm.c
> @@ -0,0 +1,163 @@
> +/*
> + *  GRUB  --  GRand Unified Bootloader
> + *  Copyright (C) 2018  Free Software Foundation, Inc.
> + *
> + *  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 .
> + *
> + *  EFI TPCM support code.
> + */
> +
> +#include 
> +#include 
> +
> +
> +static grub_uint32_t g_measured_id = STAGE_START;
> +
> +/*
> +get_tpcm_stage:
> +  TPCM does not make a distinction with the type of
> +measured target, so we use g_measured_id directly
> +for the stage.
> + */
> +static grub_uint32_t get_tpcm_stage(void)
> +{
> +grub_uint32_t stage = STAGE_INVALID;
> +
> +stage = g_measured_id;
> +
> +if (stage < STAGE_START || stage > STAGE_END)
> +stage = STAGE_INVALID;
> +
> +return stage;
> +}
> +
> +/*
> +update_measured_id:
> +  update g_measured_id +1 every time measured, and g_measured_id
> +will never be decreased.
> + */
> +static void update_measured_id(void)
> +{
> +g_measured_id++;
> +}
> +
> +/*
> +measure_memory:
> +  measure the memery region--(addr, size) through the TPCM protocol.
> +if TPCM protocol is not exist in BIOS, it will return SUCC to keep
> +compatible with non-measurement-support bios; if TPCM protocol is
> +exist but not enabled, it will also return SUCC.
> + */
> +static grub_err_t measure_memory(enum grub_file_type type
> __attribute__((unused)),
> + char *desc,
> + grub_addr_t addr,
> + grub_size_t size)
> +{
> +grub_efi_handle_t   *handles = 0;
> +grub_efi_uintn_tnum_handles;
> +grub_efi_handle_t   grub_c2p_handle = 0;
> +grub_err_t  test_c2p_err = GRUB_ERR_BAD_OS;
> +grub_guid_t c2p_guid = C2PGUID;
> +grub_uint32_t   measure_result = 0;
> +grub_uint32_t   control_result = 0;
> +grub_efi_boolean_tverify_enable = 0;
> +grub_size_t desc_len = 0;
> +
> +handles = grub_efi_locate_handle(GRUB_EFI_BY_PROTOCOL, &c2p_guid,
> NULL, &num_handles);
> +if (handles && (num_handles > 0))
> +{
> +struct c2p_protocol *c2p;
> +
> +grub_c2p_handle = handles[0];
> +grub_dprintf ("tpcm", "measue memory addr 0x%lx size 0x%lx  \n",
> addr, size);
> +c2p = grub_efi_open_protocol(grub_c2p_handle, &c2p_guid,
> +
> GRUB_EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> +if (c2p)
> +{
> +verify_enable = c2p->verify_is_enabled (c2p);
> +if (verify_enable)
> +{
> +struct addr_range range;
> +grub_efi_status_t status = 0;
> +grub_uint32_t stage = STAGE_INVALID;
> +
> +range.start  = addr;
> +range.length = size;
> +
> +stage = get_tpcm_stage();
> +if (stage != STAGE_INVALID)
> +{
> +desc_len = grub_strlen(desc) + 1;
> +status = c2p->verify_raw (c

Re: [PATCH v3 22/29] btrfs: Add ability to boot from subvolumes

[Vladimir 'phcoder' Serbinenko]

Le ven. 18 oct. 2024, 20:42, Neal Gompa  a écrit :

> On Fri, Oct 18, 2024 at 1:39 PM Vladimir 'phcoder' Serbinenko
>  wrote:
> >
> >
> >
> > Le lun. 14 oct. 2024, 20:10, Leo Sandoval  a écrit
> :
> >>
> >> From: Jeff Mahoney 
> >>
> >> This patch adds the ability to specify a different root on a btrfs
> >> filesystem too boot from other than the default one.
> >
> > Does it make available some files that are currentl y unavailable? Do
> you have an example?
>
> This is currently in use by openSUSE's boot to snapshot method, and
> people also do this on Fedora manually as we provide all the tools to
> do it.
>
Sorry but this doesn't answer my question.

>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
> ___
> 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 24/29] btrfs: export btrfs_subvol and btrfs_subvolid

[Vladimir 'phcoder' Serbinenko]

What if I put /boot and /boot/grub in different sub volumes? How do I set
variables then in order to correctly load additional modules from $prefix
and yet load correct kernels? This convoy is needed in order to load
several linuxes from the same btrfs (think installing v1 then making a
clone and upgrading one of them to v2).

Le lun. 14 oct. 2024, 20:09, Leo Sandoval  a écrit :

> From: Michael Chang 
>
> We should export btrfs_subvol and btrfs_subvolid to have both visible
> to subsidiary configuration files loaded using configfile.
>
> Signed-off-by: Michael Chang 
> ---
>  grub-core/fs/btrfs.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
> index 8e2b1e9f7..14e38a4df 100644
> --- a/grub-core/fs/btrfs.c
> +++ b/grub-core/fs/btrfs.c
> @@ -2920,6 +2920,8 @@ GRUB_MOD_INIT (btrfs)
> subvol_set_env);
>grub_register_variable_hook ("btrfs_subvolid", subvolid_get_env,
> subvolid_set_env);
> +  grub_env_export ("btrfs_subvol");
> +  grub_env_export ("btrfs_subvolid");
>  }
>
>  GRUB_MOD_FINI (btrfs)
> --
> 2.46.2
>
>
> ___
> 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 22/29] btrfs: Add ability to boot from subvolumes

[Vladimir 'phcoder' Serbinenko]

Le lun. 14 oct. 2024, 20:10, Leo Sandoval  a écrit :

> From: Jeff Mahoney 
>
> This patch adds the ability to specify a different root on a btrfs
> filesystem too boot from other than the default one.
>
Does it make available some files that are currentl y unavailable? Do you
have an example?

>
> btrfs-list-snapshots  will list the subvolumes available on the
> filesystem.
>
> set btrfs_subvol= and set btrfs_subvolid= will specify
> which subvolume to use and any pathnames provided with either of those
> variables set will start using that root. If the subvolume or subvolume id
> doesn't exist, then an error case will result.
>
> It is possible to boot into a separate GRUB instance by exporting the
> variable and loading the config file from the subvolume.
>
> Signed-off-by: Jeff Mahoney 
> ---
>  grub-core/fs/btrfs.c | 554 +--
>  include/grub/btrfs.h |   1 +
>  2 files changed, 534 insertions(+), 21 deletions(-)
>
> diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
> index ba0c58352..f14fe9c1b 100644
> --- a/grub-core/fs/btrfs.c
> +++ b/grub-core/fs/btrfs.c
> @@ -38,6 +38,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -79,9 +82,11 @@ struct grub_btrfs_superblock
>grub_uint64_t generation;
>grub_uint64_t root_tree;
>grub_uint64_t chunk_tree;
> -  grub_uint8_t dummy2[0x20];
> +  grub_uint8_t dummy2[0x18];
> +  grub_uint64_t bytes_used;
>grub_uint64_t root_dir_objectid;
> -  grub_uint8_t dummy3[0x41];
> +  grub_uint64_t num_devices;
> +  grub_uint8_t dummy3[0x39];
>struct grub_btrfs_device this_device;
>char label[0x100];
>grub_uint8_t dummy4[0x100];
> @@ -121,6 +126,7 @@ struct grub_btrfs_data
>grub_uint64_t exttree;
>grub_size_t extsize;
>struct grub_btrfs_extent_data *extent;
> +  grub_uint64_t fs_tree;
>  };
>
>  struct grub_btrfs_chunk_item
> @@ -191,6 +197,14 @@ struct grub_btrfs_leaf_descriptor
>} *data;
>  };
>
> +struct grub_btrfs_root_ref
> +{
> +  grub_uint64_t dirid;
> +  grub_uint64_t sequence;
> +  grub_uint16_t name_len;
> +  const char name[0];
> +} __attribute__ ((packed));
> +
>  struct grub_btrfs_time
>  {
>grub_int64_t sec;
> @@ -236,6 +250,14 @@ struct grub_btrfs_extent_data
>
>  #define GRUB_BTRFS_OBJECT_ID_CHUNK 0x100
>
> +#define GRUB_BTRFS_ROOT_TREE_OBJECTID 1ULL
> +#define GRUB_BTRFS_FS_TREE_OBJECTID 5ULL
> +#define GRUB_BTRFS_ROOT_REF_KEY 156
> +#define GRUB_BTRFS_ROOT_ITEM_KEY 132
> +
> +static grub_uint64_t btrfs_default_subvolid = 0;
> +static char *btrfs_default_subvol = NULL;
> +
>  static grub_disk_addr_t superblock_sectors[] = { 64 * 2, 64 * 1024 * 2,
>256 * 1048576 * 2, 1048576ULL * 1048576ULL * 2
>  };
> @@ -1252,6 +1274,62 @@ grub_btrfs_read_logical (struct grub_btrfs_data
> *data, grub_disk_addr_t addr,
>return GRUB_ERR_NONE;
>  }
>
> +static grub_err_t
> +get_fs_root(struct grub_btrfs_data *data, grub_uint64_t tree,
> +grub_uint64_t objectid, grub_uint64_t offset,
> +grub_uint64_t *fs_root);
> +
> +static grub_err_t
> +lookup_root_by_id(struct grub_btrfs_data *data, grub_uint64_t id)
> +{
> +  grub_err_t err;
> +  grub_uint64_t tree;
> +
> +  err = get_fs_root(data, data->sblock.root_tree, id, -1, &tree);
> +  if (!err)
> +data->fs_tree = tree;
> +  return err;
> +}
> +
> +static grub_err_t
> +find_path (struct grub_btrfs_data *data,
> +  const char *path, struct grub_btrfs_key *key,
> +  grub_uint64_t *tree, grub_uint8_t *type);
> +
> +static grub_err_t
> +lookup_root_by_name(struct grub_btrfs_data *data, const char *path)
> +{
> +  grub_err_t err;
> +  grub_uint64_t tree = 0;
> +  grub_uint8_t type;
> +  struct grub_btrfs_key key;
> +
> +  err = find_path (data, path, &key, &tree, &type);
> +  if (err)
> +  return grub_error(GRUB_ERR_FILE_NOT_FOUND, "couldn't locate %s\n",
> path);
> +
> +  if (key.object_id != grub_cpu_to_le64_compile_time
> (GRUB_BTRFS_OBJECT_ID_CHUNK) || tree == 0)
> +return grub_error(GRUB_ERR_BAD_FILE_TYPE, "%s: not a subvolume\n",
> path);
> +
> +  data->fs_tree = tree;
> +  return GRUB_ERR_NONE;
> +}
> +
> +static grub_err_t
> +btrfs_handle_subvol(struct grub_btrfs_data *data __attribute__ ((unused)))
> +{
> +  if (btrfs_default_subvol)
> +return lookup_root_by_name(data, btrfs_default_subvol);
> +
> +  if (btrfs_default_subvolid)
> +return lookup_root_by_id(data, btrfs_default_subvolid);
> +
> +  data->fs_tree = 0;
> +
> +  return GRUB_ERR_NONE;
> +}
> +
> +
>  static struct grub_btrfs_data *
>  grub_btrfs_mount (grub_device_t dev)
>  {
> @@ -1287,6 +1365,13 @@ grub_btrfs_mount (grub_device_t dev)
>data->devices_attached[0].dev = dev;
>data->devices_attached[0].id = data->sblock.this_device.device_id;
>
> +  err = btrfs_handle_subvol (data);
> +  if (err)
> +{
> +  grub_free (data);
> +  return NULL;
> +}
> +
>return data;
>  }
>
> @@ -1784,6 +1869,91 @@ get_root (str

Re: [PATCH] acpi: Fix out of bounds access in grub_acpi_xsdt_find_table()

[Vladimir 'phcoder' Serbinenko]

Reviewed-By: Vladimir Serbinenko phco...@gmail.com

Le mer. 16 oct. 2024, 08:22, Benjamin Herrenschmidt <
b...@kernel.crashing.org> a écrit :

> The calculation of the size of the table was incorrect (copy/pasta from
> grub_acpi_rsdt_find_table() I assume...). The entries are 64-bit long.
>
> This causes us to access beyond the end of the table which is causing
> crashes during boot on some systems. Typically this is causing a crash
> on VMWare when using UEFI and enabling serial autodetection, as
>
> grub_acpi_find_table (GRUB_ACPI_SPCR_SIGNATURE);
>
> Will goes past the end of the table (the SPCR table doesn't exits)
>
> Signed-off-by: Benjamin Herrenschmidt 
> ---
>  grub-core/kern/acpi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/grub-core/kern/acpi.c b/grub-core/kern/acpi.c
> index 48ded4e2e..8ff0835d5 100644
> --- a/grub-core/kern/acpi.c
> +++ b/grub-core/kern/acpi.c
> @@ -75,7 +75,7 @@ grub_acpi_xsdt_find_table (struct
> grub_acpi_table_header *xsdt, const char *sig)
>  return 0;
>
>ptr = (grub_unaligned_uint64_t *) (xsdt + 1);
> -  s = (xsdt->length - sizeof (*xsdt)) / sizeof (grub_uint32_t);
> +  s = (xsdt->length - sizeof (*xsdt)) / sizeof (grub_uint64_t);
>for (; s; s--, ptr++)
>  {
>struct grub_acpi_table_header *tbl;
>
>
> ___
> 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 08/16] normal: Add fw_path variable (revised)

[Vladimir 'phcoder' Serbinenko]

Le mar. 15 oct. 2024, 08:24, Michael Chang via Grub-devel <
grub-devel@gnu.org> a écrit :

> On Thu, Oct 10, 2024 at 03:43:26PM GMT, Leo Sandoval wrote:
> > From: Paulo Flabiano Smorigo 
> >
> > This patch makes grub look for its config file on efi where the app was
> > found. It was originally written by Matthew Garrett, and adapted to fix
> the
> > "No modules are loaded on grub2 network boot" issue:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=857936
> >
> > Signed-off-by: Paulo Flabiano Smorigo 
> > Signed-off-by: Robbie Harwood 
> > ---
> >  grub-core/kern/main.c   | 13 ++---
> >  grub-core/normal/main.c | 25 -
> >  2 files changed, 30 insertions(+), 8 deletions(-)
> >
> > diff --git a/grub-core/kern/main.c b/grub-core/kern/main.c
> > index 731c07c29..463dafdba 100644
> > --- a/grub-core/kern/main.c
> > +++ b/grub-core/kern/main.c
> > @@ -128,16 +128,15 @@ grub_set_prefix_and_root (void)
> >
> >grub_machine_get_bootlocation (&fwdevice, &fwpath);
> >
> > -  if (fwdevice)
> > +  if (fwdevice && fwpath)
> >  {
> > -  char *cmdpath;
> > +  char *fw_path;
> >
> > -  cmdpath = grub_xasprintf ("(%s)%s", fwdevice, fwpath ? : "");
> > -  if (cmdpath)
> > +  fw_path = grub_xasprintf ("(%s)/%s", fwdevice, fwpath);
> > +  if (fw_path)
> >   {
> > -   grub_env_set ("cmdpath", cmdpath);
> > -   grub_env_export ("cmdpath");
> > -   grub_free (cmdpath);
> > +   grub_env_set ("fw_path", fw_path);
> > +   grub_free (fw_path);
>
>
> I believe $cmdpath is an important and well-known public variable. It is
> officially documented [1], and therefore, it shouldn't be removed or
> renamed without formal notice.
>
> A quick google search [2] shows many references to $cmdpath, and many
> custom grub scripts would rely on it to function properly.
>
My thoughts exactly. I totally agree.

>
> IMHO removing or renaming it would introduce a breaking change. Adding
> $fw_path would be fine, but it's unclear to me why that would be
> necessary either.
>
> [1]
> https://www.gnu.org/software/grub/manual/grub/html_node/cmdpath.html
>
> [2]
> https://wiki.archlinux.org/title/GRUB/Tips_and_tricks
>
> https://superuser.com/questions/1757526/get-device-part-of-a-file-path-within-grub-cfg
>
> https://github.com/opencomputeproject/onie/blob/master/build-config/scripts/mk-grub-efi-image
>
> https://stackoverflow.com/questions/35269943/how-does-the-grub-2-uefi-loader-know-where-to-look-for-the-configuration-file-o
>
> Thanks,
> Michael
>
> >   }
> >  }
> >
> > diff --git a/grub-core/normal/main.c b/grub-core/normal/main.c
> > index d3f53d93d..08f48c71d 100644
> > --- a/grub-core/normal/main.c
> > +++ b/grub-core/normal/main.c
> > @@ -339,7 +339,30 @@ grub_cmd_normal (struct grub_command *cmd
> __attribute__ ((unused)),
> >/* Guess the config filename. It is necessary to make CONFIG
> static,
> >so that it won't get broken by longjmp.  */
> >char *config;
> > -  const char *prefix;
> > +  const char *prefix, *fw_path;
> > +
> > +  fw_path = grub_env_get ("fw_path");
> > +  if (fw_path)
> > + {
> > +   config = grub_xasprintf ("%s/grub.cfg", fw_path);
> > +   if (config)
> > + {
> > +   grub_file_t file;
> > +
> > +   file = grub_file_open (config, GRUB_FILE_TYPE_CONFIG);
> > +   if (file)
> > + {
> > +   grub_file_close (file);
> > +   grub_enter_normal_mode (config);
> > + }
> > +  else
> > +{
> > +  /*  Ignore all errors.  */
> > +  grub_errno = 0;
> > +}
> > +   grub_free (config);
> > + }
> > + }
> >
> >prefix = grub_env_get ("prefix");
> >if (prefix)
> > --
> > 2.46.2
> >
> >
> > ___
> > 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
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Add NVMe driver for native targets

[Vladimir 'phcoder' Serbinenko]

Thank you for your effort but we already have nvme driver in the review
queue. See my email from 16th of May

Le dim. 13 oct. 2024, 22:38,  a écrit :

> From: Mate Kukri 
>
> It is based on existing SeaBIOS code, so the license is LGPLv3.
>
> Tested as a coreboot paload on the following targets:
> - QEMU Q35 with emulated NVMe disk
> - ASUS H610M-K with Intel 660p NVME disk
>
> Signed-off-by: Mate Kukri 
> ---
>  Makefile.am |   2 +-
>  grub-core/Makefile.core.def |   6 +
>  grub-core/commands/nativedisk.c |   1 +
>  grub-core/disk/nvme.c   | 861 
>  include/grub/disk.h |   1 +
>  include/grub/nvme.h | 225 +
>  6 files changed, 1095 insertions(+), 1 deletion(-)
>  create mode 100644 grub-core/disk/nvme.c
>  create mode 100644 include/grub/nvme.h
>
> diff --git a/Makefile.am b/Makefile.am
> index 43635d5ff..2c86dbbf6 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -434,7 +434,7 @@ if COND_i386_coreboot
>  FS_PAYLOAD_MODULES ?= $(shell cat grub-core/fs.lst)
>  default_payload.elf: grub-mkstandalone grub-mkimage FORCE
> test -f $@ && rm $@ || true
> -   pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O
> i386-coreboot -o $@ --modules='ahci pata ehci uhci ohci usb_keyboard usbms
> part_msdos ext2 fat at_keyboard part_gpt usbserial_usbdebug cbfs'
> --install-modules='ls linux search configfile normal cbtime cbls memrw iorw
> minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi chain
> test serial multiboot cbmemc linux16 gzio echo help syslinuxcfg xnu
> $(FS_PAYLOAD_MODULES) password_pbkdf2 $(EXTRA_PAYLOAD_MODULES)' --fonts=
> --themes= --locales= -d grub-core/
> /boot/grub/grub.cfg=$(srcdir)/coreboot.cfg
> +   pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O
> i386-coreboot -o $@ --modules='ahci pata nvme ehci uhci ohci usb_keyboard
> usbms part_msdos ext2 fat at_keyboard part_gpt usbserial_usbdebug cbfs'
> --install-modules='ls linux search configfile normal cbtime cbls memrw iorw
> minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi chain
> test serial multiboot cbmemc linux16 gzio echo help syslinuxcfg xnu
> $(FS_PAYLOAD_MODULES) password_pbkdf2 $(EXTRA_PAYLOAD_MODULES)' --fonts=
> --themes= --locales= -d grub-core/
> /boot/grub/grub.cfg=$(srcdir)/coreboot.cfg
>  endif
>
>  endif
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index 063ef5dd7..7b4cf972a 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -2606,3 +2606,9 @@ module = {
>enable = efi;
>depends = part_gpt;
>  };
> +
> +module = {
> +  name = nvme;
> +  common = disk/nvme.c;
> +  enable = pci;
> +};
> diff --git a/grub-core/commands/nativedisk.c
> b/grub-core/commands/nativedisk.c
> index 580c8d3b0..a2c766fbd 100644
> --- a/grub-core/commands/nativedisk.c
> +++ b/grub-core/commands/nativedisk.c
> @@ -78,6 +78,7 @@ get_uuid (const char *name, char **uuid, int getnative)
>  case GRUB_DISK_DEVICE_ATA_ID:
>  case GRUB_DISK_DEVICE_SCSI_ID:
>  case GRUB_DISK_DEVICE_XEN:
> +case GRUB_DISK_DEVICE_NVME_ID:
>if (getnative)
> break;
>/* FALLTHROUGH */
> diff --git a/grub-core/disk/nvme.c b/grub-core/disk/nvme.c
> new file mode 100644
> index 0..b6a886464
> --- /dev/null
> +++ b/grub-core/disk/nvme.c
> @@ -0,0 +1,861 @@
> +/* nvme.c - NVMe support. */
> +/*
> + * Based on SeaBIOS NVMe driver, ported to GRUB2 by Mate Kukri
> + *
> + * Copyright 2017 Amazon.com, Inc. or its affiliates.
> + * Copyright 2024 Mate Kukri 
> + *
> + * This file may be distributed under the terms of the GNU LGPLv3 license.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +GRUB_MOD_LICENSE ("GPLv3");/* LGPLv3 is GPLv3 compatible */
> +
> +static grub_uint32_t grub_nvme_ctrlcnt;
> +static grub_uint32_t grub_nvme_nscnt;
> +
> +static struct grub_nvme_namespace *grub_nvme_namespaces;
> +
> +/* Page aligned "dma bounce buffer" of size GRUB_NVME_PAGE_SIZE */
> +static void *nvme_dma_buffer;
> +
> +static void *
> +zalloc_page_aligned (grub_uint32_t size)
> +{
> +  void *res = grub_memalign (GRUB_NVME_PAGE_SIZE, size);
> +  if (res)
> +grub_memset (res, 0, size);
> +  return res;
> +}
> +
> +static void
> +nvme_init_queue_common (struct grub_nvme_ctrl *ctrl,
> +   struct grub_nvme_queue *q, grub_uint16_t q_idx,
> +   grub_uint16_t length)
> +{
> +  grub_memset (q, 0, sizeof (*q));
> +  q->dbl =
> +(grub_uint32_t *) ((char *) ctrl->reg + 0x1000 +
> +  q_idx * ctrl->doorbell_stride);
> +  grub_dprintf ("nvme", " q %p q_idx %u dbl %p\n", q, q_idx, q->dbl);
> +  q->mask = length - 1;
> +}
> +
> +static int
> +nvme_init_sq (struct grub_nvme_ctrl *ctrl, struct grub_nvme_sq *sq,
> + grub_uint16_t q_idx, grub_uint16_t length,
> + struct grub_nvme_cq *cq)
> +{
> +  nvme_init_qu

Re: [PATCH v1 22/37] bootp: New net_bootp6 command

[Vladimir 'phcoder' Serbinenko]

Le mar. 8 oct. 2024, 10:23, Michael Chang via Grub-devel 
a écrit :

> On Mon, Oct 07, 2024 at 12:20:55PM GMT, Leo Sandoval wrote:
> > From: Michael Chang 
> >
> > Implement new net_bootp6 command for IPv6 network auto configuration via
> the
> > DHCPv6 protocol (RFC3315).
>
> This would have marked the fourth attempt to upstream the patch by
> different people.
>
> https://lists.gnu.org/archive/html/grub-devel/2016-08/msg0.html
> https://lists.gnu.org/archive/html/grub-devel/2023-01/msg00012.html
> https://www.mail-archive.com/grub-devel@gnu.org/msg30432.html
>
> If everything is still desirable, I could help by reposting the series
> in a separate thread to ease the review,

Please do

> but I’m not really sure because
> it seems to me that upstream isn't interested in the feature.
>
We're. Just our throughput is limited and patches fall through the cracks

>
> Thanks,
> Michael
>
> >
> > Signed-off-by: Michael Chang 
> > Signed-off-by: Ken Lin 
> > [pjones: Put back our code to add a local route]
> > Signed-off-by: Peter Jones 
> > ---
> >  grub-core/net/bootp.c  | 1059 +++-
> >  grub-core/net/drivers/efi/efinet.c |   18 +-
> >  grub-core/net/ip.c |   39 +
> >  include/grub/efi/api.h |2 +-
> >  include/grub/net.h |   91 ++-
> >  5 files changed, 1001 insertions(+), 208 deletions(-)
> >
> > diff --git a/grub-core/net/bootp.c b/grub-core/net/bootp.c
> > index 02d2c2614..e0aec2523 100644
> > --- a/grub-core/net/bootp.c
> > +++ b/grub-core/net/bootp.c
> > @@ -24,6 +24,98 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +
> > +static int
> > +dissect_url (const char *url, char **proto, char **host, char **path)
> > +{
> > +  const char *p, *ps;
> > +  grub_size_t l;
> > +
> > +  *proto = *host = *path = NULL;
> > +  ps = p = url;
> > +
> > +  while ((p = grub_strchr (p, ':')))
> > +{
> > +  if (grub_strlen (p) < sizeof ("://") - 1)
> > + break;
> > +  if (grub_memcmp (p, "://", sizeof ("://") - 1) == 0)
> > + {
> > +   l = p - ps;
> > +   *proto = grub_malloc (l + 1);
> > +   if (!*proto)
> > + {
> > +   grub_print_error ();
> > +   return 0;
> > + }
> > +
> > +   grub_memcpy (*proto, ps, l);
> > +   (*proto)[l] = '\0';
> > +   p +=  sizeof ("://") - 1;
> > +   break;
> > + }
> > +  ++p;
> > +}
> > +
> > +  if (!*proto)
> > +{
> > +  grub_dprintf ("bootp", "url: %s is not valid, protocol not
> found\n", url);
> > +  return 0;
> > +}
> > +
> > +  ps = p;
> > +  p = grub_strchr (p, '/');
> > +
> > +  if (!p)
> > +{
> > +  grub_dprintf ("bootp", "url: %s is not valid, host/path not
> found\n", url);
> > +  grub_free (*proto);
> > +  *proto = NULL;
> > +  return 0;
> > +}
> > +
> > +  l = p - ps;
> > +
> > +  if (l > 2 && ps[0] == '[' && ps[l - 1] == ']')
> > +{
> > +  *host = grub_malloc (l - 1);
> > +  if (!*host)
> > + {
> > +   grub_print_error ();
> > +   grub_free (*proto);
> > +   *proto = NULL;
> > +   return 0;
> > + }
> > +  grub_memcpy (*host, ps + 1, l - 2);
> > +  (*host)[l - 2] = 0;
> > +}
> > +  else
> > +{
> > +  *host = grub_malloc (l + 1);
> > +  if (!*host)
> > + {
> > +   grub_print_error ();
> > +   grub_free (*proto);
> > +   *proto = NULL;
> > +   return 0;
> > + }
> > +  grub_memcpy (*host, ps, l);
> > +  (*host)[l] = 0;
> > +}
> > +
> > +  *path = grub_strdup (p);
> > +  if (!*path)
> > +{
> > +  grub_print_error ();
> > +  grub_free (*host);
> > +  grub_free (*proto);
> > +  *host = NULL;
> > +  *proto = NULL;
> > +  return 0;
> > +}
> > +  return 1;
> > +}
> >
> >  struct grub_dhcp_discover_options
> >  {
> > @@ -610,6 +702,584 @@ out:
> >return err;
> >  }
> >
> > +/* The default netbuff size for sending DHCPv6 packets which should be
> > +   large enough to hold the information */
> > +#define GRUB_DHCP6_DEFAULT_NETBUFF_ALLOC_SIZE 512
> > +
> > +struct grub_dhcp6_options
> > +{
> > +  grub_uint8_t *client_duid;
> > +  grub_uint16_t client_duid_len;
> > +  grub_uint8_t *server_duid;
> > +  grub_uint16_t server_duid_len;
> > +  grub_uint32_t iaid;
> > +  grub_uint32_t t1;
> > +  grub_uint32_t t2;
> > +  grub_net_network_level_address_t *ia_addr;
> > +  grub_uint32_t preferred_lifetime;
> > +  grub_uint32_t valid_lifetime;
> > +  grub_net_network_level_address_t *dns_server_addrs;
> > +  grub_uint16_t num_dns_server;
> > +  char *boot_file_proto;
> > +  char *boot_file_server_ip;
> > +  char *boot_file_path;
> > +};
> > +
> > +typedef struct grub_dhcp6_options *grub_dhcp6_options_t;
> > +
> > +struct grub_dhcp6_session
> > +{
> > +  struct grub_dhcp6_session *next;
> > +  struct grub_dhcp6_session **prev;
> > +  grub_uint32_t iaid;
> > +  grub_uint32_t transaction_id:24;
> > +  grub_uint64_t start_time;
> > +

Re: [PATCH v1 31/37] btrfs: grub2-btrfs-04-grub2-install

[Vladimir 'phcoder' Serbinenko]

Le mar. 8 oct. 2024, 09:53, Michael Chang via Grub-devel 
a écrit :

> On Tue, Oct 08, 2024 at 08:07:17AM GMT, Vladimir 'phcoder' Serbinenko
> wrote:
> > Again, what do you try to achieve? Why aren't absolute paths enough?
>
> The absolute path does not align with the default subvolume. As a
> result, after running btrfs set-default , the system does not
> boot the new default subvolume as expected. Instead, it continues to
> boot from a fixed subvolume.
>
Yes, this is the intended behavior. When you change mount points or mount
options they are not propagated either. We can have a command to retrieve
default subvolume:
btrfs_default_subvolume --set=subvol /
linux /$subvol/boot/vmlinuz
This way you can still e.g. do operations with different subvols like:
if cmp /$subvol/grub.cfg /vol2/grub.cfg; then
...
fi

>
> Thanks,
> Michael
>
> >
> > Le lun. 7 oct. 2024, 21:23, Leo Sandoval  a écrit :
> >
> > > From: Michael Chang 
> > >
> > > Signed-off-by: Michael Chang 
> > > Signed-off-by: Robbie Harwood 
> > > ---
> > >  grub-core/osdep/linux/getroot.c |  7 +++
> > >  grub-core/osdep/unix/config.c   | 17 +++--
> > >  include/grub/emu/config.h   |  1 +
> > >  util/config.c   | 10 ++
> > >  util/grub-install.c | 14 ++
> > >  util/grub-mkrelpath.c   |  6 ++
> > >  6 files changed, 53 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/grub-core/osdep/linux/getroot.c
> > > b/grub-core/osdep/linux/getroot.c
> > > index 7dd775d2a..7c29b3523 100644
> > > --- a/grub-core/osdep/linux/getroot.c
> > > +++ b/grub-core/osdep/linux/getroot.c
> > > @@ -373,6 +373,7 @@ get_btrfs_fs_prefix (const char *mount_path)
> > >return NULL;
> > >  }
> > >
> > > +int use_relative_path_on_btrfs = 0;
> > >
> > >  char **
> > >  grub_find_root_devices_from_mountinfo (const char *dir, char
> **relroot)
> > > @@ -516,6 +517,12 @@ again:
> > > {
> > >   ret = grub_find_root_devices_from_btrfs (dir);
> > >   fs_prefix = get_btrfs_fs_prefix (entries[i].enc_path);
> > > + if (use_relative_path_on_btrfs)
> > > +   {
> > > + if (fs_prefix)
> > > +   free (fs_prefix);
> > > + fs_prefix = xstrdup ("/");
> > > +   }
> > > }
> > >else if (!retry && grub_strcmp (entries[i].fstype, "autofs") ==
> 0)
> > > {
> > > diff --git a/grub-core/osdep/unix/config.c
> b/grub-core/osdep/unix/config.c
> > > index 0b1f7618d..0ce0e309a 100644
> > > --- a/grub-core/osdep/unix/config.c
> > > +++ b/grub-core/osdep/unix/config.c
> > > @@ -82,6 +82,19 @@ grub_util_load_config (struct grub_util_config *cfg)
> > >if (v)
> > >  cfg->grub_distributor = xstrdup (v);
> > >
> > > +  v = getenv ("SUSE_BTRFS_SNAPSHOT_BOOTING");
> > > +  if (v)
> > > +{
> > > +  if (grub_strncmp(v, "true", sizeof ("true") - 1) == 0)
> > > +{
> > > +  cfg->is_suse_btrfs_snapshot_enabled = 1;
> > > +}
> > > +  else
> > > +{
> > > +  cfg->is_suse_btrfs_snapshot_enabled = 0;
> > > +}
> > > +}
> > > +
> > >cfgfile = grub_util_get_config_filename ();
> > >if (!grub_util_is_regular (cfgfile))
> > >  return;
> > > @@ -105,8 +118,8 @@ grub_util_load_config (struct grub_util_config
> *cfg)
> > >*ptr++ = *iptr;
> > >  }
> > >
> > > -  strcpy (ptr, "'; printf
> > > \"GRUB_ENABLE_CRYPTODISK=%s\\nGRUB_DISTRIBUTOR=%s\\n\" "
> > > - "\"$GRUB_ENABLE_CRYPTODISK\" \"$GRUB_DISTRIBUTOR\"");
> > > +  strcpy (ptr, "'; printf
> > >
> \"GRUB_ENABLE_CRYPTODISK=%s\\nGRUB_DISTRIBUTOR=%s\\nSUSE_BTRFS_SNAPSHOT_BOOTING=%s\\n\"
> > > "
> > > + "\"$GRUB_ENABLE_CRYPTODISK\" \"$GRUB_DISTRIBUTOR\"
> > > \"$SUSE_BTRFS_SNAPSHOT_BOOTING\"");
> > >
> > >argv[2] = script;
> > >argv[3] = '\0';
> > > diff --git a/include/grub/emu/config.h b/include/grub/emu/config.h
> > > index 875d5896c..c9a7e5f4a 100644
> > 

Re: [PATCH v2 03/17] ieee1275: Disable GRUB video support for IBM power machines

[Vladimir 'phcoder' Serbinenko]

Can you add a short comment in cmain why it's needed? It should mention
32-bit address truncation. The story in the commit message, on the other
hand, is way too long. It needs to be summarized with a link to full story.

Le lun. 7 oct. 2024, 21:19, Leo Sandoval  a écrit :

> From: Paulo Flabiano Smorigo 
>
> Disable GRUB Video Support from IBM Power Machines. This patch fixes what
> is describe above and should fix
> https://bugzilla.redhat.com/show_bug.cgi?id=973205.
> C&P  the bz
> problem's description:
>
> Grub crashes if it tries to run in video mode.
>
> I'm currently testing with grub rpm from f18 in a lpar inside a Power 7R2
> machine using a matrox video card attached.
>
> To reproduce you need to redirect the console to the video output.
>
> This will happens:
>
> IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
> IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
> IBM IBM IBM IBM IBM IBM STARTING SOFTWARE   IBM IBM IBM IBM IBM IBM
> IBM IBM IBM IBM IBM IBMPLEASE WAIT...   IBM IBM IBM IBM IBM IBM
> IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
> IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
> IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
> IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
> IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
> IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
> IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
> IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
> IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
> IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
> IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
> IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
>
> Welcome to GRUB
>
> DEFAULT CATCH!, exception-handler=fff00300
> at   %SRR0: 0020ac80   %SRR1: 3002
> Open Firmware exception handler entered from non-OF code
>
> Client's Fix Pt Regs:
>  00 00780c38 01adfc40  1800
>  04 00780850 0004afff 001d2bb0 
>  08 1800 fffb5000 1804b000 01adfc50
>  0c 0008  00800050 0266
>  10 0265 0270 026e 0267
>  14 0263 0001 001a 0002
>  18 0002  00780dce 8080
>  1c 0067 001d3de0 001d2b30 0002
> Special Regs:
> %IV: 0300 %CR: 22002084%XER: 2000  %DSISR: 4200
>   %SRR0: 0020ac80   %SRR1: 3002
> %LR: 6584%CTR: 0004b000
>%DAR: 1804afff
> Virtual PID = 0
>  ok
> 0 >
>
> In Power, GRUB has video support and works fine with PowerMAC.
>
> Theorically it should works with IBM machines as well but, using a Matrox
> videocard and grub.cfg with the video option enabled, GRUB crashes as we
> saw above.
>
> Using GRUB debug we saw that the crash happens because GRUB tries to
> access the video card address:
>
> video/ieee1275.c:236: IEEE1275: keeping current mode 640x480
> video/ieee1275.c:266: IEEE1275: initialising FB @ 0x1800 640x480x8
>
> GRUB gets the address from the display card node from openfirmware. The
> property is called "address":
>
> 0 > dev /pci@800200d/pci@0/display@0  ok
> 0 > .properties
> ibm,loc-codeU78AB.001.WZSHS9P-P1-C7-T1
> vendor-id   102b
> device-id   2527
> revision-id 0001
> class-code  0003
> interrupts  0001
> min-grant   0010
> max-latency 0020
> subsystem-vendor-id 102b
> subsystem-id2300
> devsel-speed0001
> fast-back-to-back
> built-in
> namedisplay
> compatible  MTRX,G550
> pci102b,2527
> pciclass,03
> display
> reg 0099     
> 02990030     0001
> 02990010     0400
> 02990014     0080
> 02990018     0080
> fcode-rom-offset9000
> device_type display
> character-set   ISO8859-1
> iso6429-1983-colors
> power-consumption     007270e0 007270e0 
>  007b98a0 0

Re: [PATCH v2 11/17] 00_header.in: Enable pager by default. (#985860)

[Vladimir 'phcoder' Serbinenko]

This has a danger of rendering headless systems unbootable while waiting
for user input

Le lun. 7 oct. 2024, 21:19, Leo Sandoval  a écrit :

> From: Peter Jones 
>
> Signed-off-by: Peter Jones 
> ---
>  util/grub.d/00_header.in | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/util/grub.d/00_header.in b/util/grub.d/00_header.in
> index 6a316a5ba..c2d8b0937 100644
> --- a/util/grub.d/00_header.in
> +++ b/util/grub.d/00_header.in
> @@ -43,6 +43,8 @@ if [ "x${GRUB_DEFAULT_BUTTON}" = "xsaved" ] ; then
> GRUB_DEFAULT_BUTTON='${saved_
>  if [ "x${GRUB_TIMEOUT_BUTTON}" = "x" ] ; then
> GRUB_TIMEOUT_BUTTON="$GRUB_TIMEOUT" ; fi
>
>  cat << EOF
> +set pager=1
> +
>  if [ -s \$prefix/grubenv ]; then
>load_env
>  fi
> --
> 2.46.2
>
>
> ___
> 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 v1 24/37] backtrace: Make grub_fatal() also backtrace

[Vladimir 'phcoder' Serbinenko]

This increases the core size on i386-pc needlessly. And will increase even
more when we improve backtrace command. This needs to be a hook and loaded
together with normal. Also it needs to be cpu-agnostic

Le lun. 7 oct. 2024, 21:22, Leo Sandoval  a écrit :

> From: Peter Jones 
>
> ---
>  grub-core/Makefile.core.def |  3 ++
>  grub-core/kern/misc.c   |  6 
>  grub-core/lib/arm64/backtrace.c | 62 +
>  grub-core/lib/backtrace.c   |  2 ++
>  grub-core/lib/i386/backtrace.c  | 14 +++-
>  5 files changed, 86 insertions(+), 1 deletion(-)
>  create mode 100644 grub-core/lib/arm64/backtrace.c
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index 0bffbfea9..17b581220 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -199,6 +199,9 @@ kernel = {
>
>softdiv = lib/division.c;
>
> +  x86 = lib/i386/backtrace.c;
> +  x86 = lib/backtrace.c;
> +
>i386 = kern/i386/dl.c;
>i386_xen = kern/i386/dl.c;
>i386_xen_pvh = kern/i386/dl.c;
> diff --git a/grub-core/kern/misc.c b/grub-core/kern/misc.c
> index 11037dc02..465a8e74e 100644
> --- a/grub-core/kern/misc.c
> +++ b/grub-core/kern/misc.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  union printf_arg
>  {
> @@ -1301,6 +1302,11 @@ grub_printf_fmt_check (const char *fmt, const char
> *fmt_expected)
>  void __attribute__ ((noreturn))
>  grub_abort (void)
>  {
> +#ifndef GRUB_UTIL
> +#if defined(__i386__) || defined(__x86_64__)
> +  grub_backtrace();
> +#endif
> +#endif
>grub_printf ("\nAborted.");
>
>  #ifndef GRUB_UTIL
> diff --git a/grub-core/lib/arm64/backtrace.c
> b/grub-core/lib/arm64/backtrace.c
> new file mode 100644
> index 0..1079b5380
> --- /dev/null
> +++ b/grub-core/lib/arm64/backtrace.c
> @@ -0,0 +1,62 @@
> +/*
> + *  GRUB  --  GRand Unified Bootloader
> + *  Copyright (C) 2009  Free Software Foundation, Inc.
> + *
> + *  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 .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MAX_STACK_FRAME 102400
> +
> +void
> +grub_backtrace_pointer (int frame)
> +{
> +  while (1)
> +{
> +  void *lp = __builtin_return_address (frame);
> +  if (!lp)
> +   break;
> +
> +  lp = __builtin_extract_return_addr (lp);
> +
> +  grub_printf ("%p: ", lp);
> +  grub_backtrace_print_address (lp);
> +  grub_printf (" (");
> +  for (i = 0; i < 2; i++)
> +   grub_printf ("%p,", ((void **)ptr) [i + 2]);
> +  grub_printf ("%p)\n", ((void **)ptr) [i + 2]);
> +  nptr = *(void **)ptr;
> +  if (nptr < ptr || (void **) nptr - (void **) ptr > MAX_STACK_FRAME
> + || nptr == ptr)
> +   {
> + grub_printf ("Invalid stack frame at %p (%p)\n", ptr, nptr);
> + break;
> +   }
> +  ptr = nptr;
> +}
> +}
> +
> +void
> +grub_backtrace (void)
> +{
> +  grub_backtrace_pointer (1);
> +}
> +
> diff --git a/grub-core/lib/backtrace.c b/grub-core/lib/backtrace.c
> index 825a8800e..c0ad6ab8b 100644
> --- a/grub-core/lib/backtrace.c
> +++ b/grub-core/lib/backtrace.c
> @@ -29,6 +29,7 @@ GRUB_MOD_LICENSE ("GPLv3+");
>  void
>  grub_backtrace_print_address (void *addr)
>  {
> +#ifndef GRUB_UTIL
>grub_dl_t mod;
>
>FOR_DL_MODULES (mod)
> @@ -44,6 +45,7 @@ grub_backtrace_print_address (void *addr)
> }
>}
>
> +#endif
>grub_printf ("%p", addr);
>  }
>
> diff --git a/grub-core/lib/i386/backtrace.c
> b/grub-core/lib/i386/backtrace.c
> index c3e03c727..c67273db3 100644
> --- a/grub-core/lib/i386/backtrace.c
> +++ b/grub-core/lib/i386/backtrace.c
> @@ -15,11 +15,23 @@
>   *  You should have received a copy of the GNU General Public License
>   *  along with GRUB.  If not, see .
>   */
> +#include 
> +#ifdef GRUB_UTIL
> +#define REALLY_GRUB_UTIL GRUB_UTIL
> +#undef GRUB_UTIL
> +#endif
> +
> +#include 
> +#include 
> +
> +#ifdef REALLY_GRUB_UTIL
> +#define GRUB_UTIL REALLY_GRUB_UTIL
> +#undef REALLY_GRUB_UTIL
> +#endif
>
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> --
> 2.46.2
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
__

Re: [PATCH v1 28/37] btrfs: fix a bad null check

[Vladimir 'phcoder' Serbinenko]

LGTM
Reviewed-by: Vladimir Serbinenko phco...@gmail.com


Le lun. 7 oct. 2024, 21:23, Leo Sandoval  a écrit :

> From: Peter Jones 
>
> current gcc complains:
>
>   grub-core/fs/btrfs.c: In function ‘grub_cmd_btrfs_info’:
>   grub-core/fs/btrfs.c:2745:7: error: the comparison will always evaluate
> as ‘true’ for the address of ‘label’ will never be NULL [-Werror=address]
>2745 |   if (data->sblock.label)
> |   ^~~~
>   grub-core/fs/btrfs.c:92:8: note: ‘label’ declared here
>  92 |   char label[0x100];
> |^
>   cc1: all warnings being treated as errors
>
> Obviously this check should be on the first data byte instead of the
> symbol itself.
>
> Signed-off-by: Peter Jones 
> ---
>  grub-core/fs/btrfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
> index f14fe9c1b..8e2b1e9f7 100644
> --- a/grub-core/fs/btrfs.c
> +++ b/grub-core/fs/btrfs.c
> @@ -2625,7 +2625,7 @@ grub_cmd_btrfs_info (grub_command_t cmd
> __attribute__ ((unused)), int argc,
>return grub_error (GRUB_ERR_BAD_ARGUMENT, "failed to open fs");
>  }
>
> -  if (data->sblock.label)
> +  if (data->sblock.label[0])
>  grub_printf("Label: '%s' ", data->sblock.label);
>else
>  grub_printf("Label: none ");
> --
> 2.46.2
>
>
> ___
> 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 v1 31/37] btrfs: grub2-btrfs-04-grub2-install

[Vladimir 'phcoder' Serbinenko]

Again, what do you try to achieve? Why aren't absolute paths enough?

Le lun. 7 oct. 2024, 21:23, Leo Sandoval  a écrit :

> From: Michael Chang 
>
> Signed-off-by: Michael Chang 
> Signed-off-by: Robbie Harwood 
> ---
>  grub-core/osdep/linux/getroot.c |  7 +++
>  grub-core/osdep/unix/config.c   | 17 +++--
>  include/grub/emu/config.h   |  1 +
>  util/config.c   | 10 ++
>  util/grub-install.c | 14 ++
>  util/grub-mkrelpath.c   |  6 ++
>  6 files changed, 53 insertions(+), 2 deletions(-)
>
> diff --git a/grub-core/osdep/linux/getroot.c
> b/grub-core/osdep/linux/getroot.c
> index 7dd775d2a..7c29b3523 100644
> --- a/grub-core/osdep/linux/getroot.c
> +++ b/grub-core/osdep/linux/getroot.c
> @@ -373,6 +373,7 @@ get_btrfs_fs_prefix (const char *mount_path)
>return NULL;
>  }
>
> +int use_relative_path_on_btrfs = 0;
>
>  char **
>  grub_find_root_devices_from_mountinfo (const char *dir, char **relroot)
> @@ -516,6 +517,12 @@ again:
> {
>   ret = grub_find_root_devices_from_btrfs (dir);
>   fs_prefix = get_btrfs_fs_prefix (entries[i].enc_path);
> + if (use_relative_path_on_btrfs)
> +   {
> + if (fs_prefix)
> +   free (fs_prefix);
> + fs_prefix = xstrdup ("/");
> +   }
> }
>else if (!retry && grub_strcmp (entries[i].fstype, "autofs") == 0)
> {
> diff --git a/grub-core/osdep/unix/config.c b/grub-core/osdep/unix/config.c
> index 0b1f7618d..0ce0e309a 100644
> --- a/grub-core/osdep/unix/config.c
> +++ b/grub-core/osdep/unix/config.c
> @@ -82,6 +82,19 @@ grub_util_load_config (struct grub_util_config *cfg)
>if (v)
>  cfg->grub_distributor = xstrdup (v);
>
> +  v = getenv ("SUSE_BTRFS_SNAPSHOT_BOOTING");
> +  if (v)
> +{
> +  if (grub_strncmp(v, "true", sizeof ("true") - 1) == 0)
> +{
> +  cfg->is_suse_btrfs_snapshot_enabled = 1;
> +}
> +  else
> +{
> +  cfg->is_suse_btrfs_snapshot_enabled = 0;
> +}
> +}
> +
>cfgfile = grub_util_get_config_filename ();
>if (!grub_util_is_regular (cfgfile))
>  return;
> @@ -105,8 +118,8 @@ grub_util_load_config (struct grub_util_config *cfg)
>*ptr++ = *iptr;
>  }
>
> -  strcpy (ptr, "'; printf
> \"GRUB_ENABLE_CRYPTODISK=%s\\nGRUB_DISTRIBUTOR=%s\\n\" "
> - "\"$GRUB_ENABLE_CRYPTODISK\" \"$GRUB_DISTRIBUTOR\"");
> +  strcpy (ptr, "'; printf
> \"GRUB_ENABLE_CRYPTODISK=%s\\nGRUB_DISTRIBUTOR=%s\\nSUSE_BTRFS_SNAPSHOT_BOOTING=%s\\n\"
> "
> + "\"$GRUB_ENABLE_CRYPTODISK\" \"$GRUB_DISTRIBUTOR\"
> \"$SUSE_BTRFS_SNAPSHOT_BOOTING\"");
>
>argv[2] = script;
>argv[3] = '\0';
> diff --git a/include/grub/emu/config.h b/include/grub/emu/config.h
> index 875d5896c..c9a7e5f4a 100644
> --- a/include/grub/emu/config.h
> +++ b/include/grub/emu/config.h
> @@ -37,6 +37,7 @@ struct grub_util_config
>  {
>int is_cryptodisk_enabled;
>char *grub_distributor;
> +  int is_suse_btrfs_snapshot_enabled;
>  };
>
>  void
> diff --git a/util/config.c b/util/config.c
> index ebcdd8f5e..f044a880a 100644
> --- a/util/config.c
> +++ b/util/config.c
> @@ -42,6 +42,16 @@ grub_util_parse_config (FILE *f, struct
> grub_util_config *cfg, int simple)
> cfg->is_cryptodisk_enabled = 1;
>   continue;
> }
> +  if (grub_strncmp (ptr, "SUSE_BTRFS_SNAPSHOT_BOOTING=",
> +   sizeof ("SUSE_BTRFS_SNAPSHOT_BOOTING=") - 1) == 0)
> +   {
> + ptr += sizeof ("SUSE_BTRFS_SNAPSHOT_BOOTING=") - 1;
> + if (*ptr == '"' || *ptr == '\'')
> +   ptr++;
> + if (grub_strncmp(ptr, "true", sizeof ("true") - 1) == 0)
> +   cfg->is_suse_btrfs_snapshot_enabled = 1;
> + continue;
> +   }
>if (grub_strncmp (ptr, "GRUB_DISTRIBUTOR=",
> sizeof ("GRUB_DISTRIBUTOR=") - 1) == 0)
> {
> diff --git a/util/grub-install.c b/util/grub-install.c
> index 7dc5657bb..ec3ed4967 100644
> --- a/util/grub-install.c
> +++ b/util/grub-install.c
> @@ -843,6 +843,8 @@ try_open (const char *path)
>  }
>  #endif
>
> +extern int use_relative_path_on_btrfs;
> +
>  int
>  main (int argc, char *argv[])
>  {
> @@ -876,6 +878,9 @@ main (int argc, char *argv[])
>
>grub_util_load_config (&config);
>
> +  if (config.is_suse_btrfs_snapshot_enabled)
> +use_relative_path_on_btrfs = 1;
> +
>if (!bootloader_id && config.grub_distributor)
>  {
>char *ptr;
> @@ -1366,6 +1371,15 @@ main (int argc, char *argv[])
>relative_grubdir = xstrdup ("/");
>  }
>
> +  if (config.is_suse_btrfs_snapshot_enabled
> +  && grub_strncmp(grub_fs->name, "btrfs", sizeof ("btrfs") - 1) == 0)
> +{
> +  if (!load_cfg_f)
> +load_cfg_f = grub_util_fopen (load_cfg, "wb");
> +  have_load_cfg = 1;
> +  fprintf (load_cfg_f, "set btrfs_relative_path='y'\n");
> +}
> +
>char *prefix_drive = NULL;
>char *install

Re: [PATCH v1 25/37] grub.texi: Make our info pages say "grub2" where appropriate.

[Vladimir 'phcoder' Serbinenko]

Upstream uses "grub" for these commands. Rename to "grub2" is
distro-specific

Le lun. 7 oct. 2024, 21:23, Leo Sandoval  a écrit :

> From: Peter Jones 
>
> This needs to be hooked up to --program-transform=, but I haven't had
> time.
>
> Signed-off-by: Peter Jones 
> ---
>  docs/grub-dev.texi|   4 +-
>  docs/grub.texi| 359 ++
>  grub-core/kern/misc.c |   2 +-
>  3 files changed, 191 insertions(+), 174 deletions(-)
>
> diff --git a/docs/grub-dev.texi b/docs/grub-dev.texi
> index 1276c5930..04c6678cb 100644
> --- a/docs/grub-dev.texi
> +++ b/docs/grub-dev.texi
> @@ -1,7 +1,7 @@
>  \input texinfo
>  @c -*-texinfo-*-
>  @c %**start of header
> -@setfilename grub-dev.info
> +@setfilename grub2-dev.info
>  @include version-dev.texi
>  @settitle GNU GRUB Developers Manual @value{VERSION}
>  @c Unify all our little indices for now.
> @@ -32,7 +32,7 @@ Invariant Sections.
>
>  @dircategory Kernel
>  @direntry
> -* grub-dev: (grub-dev). The GRand Unified Bootloader Dev
> +* grub2-dev: (grub2-dev). The GRand Unified Bootloader Dev
>  @end direntry
>
>  @setchapternewpage odd
> diff --git a/docs/grub.texi b/docs/grub.texi
> index a225f9a88..cecf14d55 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -1,7 +1,7 @@
>  \input texinfo
>  @c -*-texinfo-*-
>  @c %**start of header
> -@setfilename grub.info
> +@setfilename grub2.info
>  @include version.texi
>  @settitle GNU GRUB Manual @value{VERSION}
>  @c Unify all our little indices for now.
> @@ -32,15 +32,15 @@ Invariant Sections.
>
>  @dircategory Kernel
>  @direntry
> -* GRUB: (grub). The GRand Unified Bootloader
> -* grub-install: (grub)Invoking grub-install.Install GRUB on your drive
> -* grub-mkconfig: (grub)Invoking grub-mkconfig.  Generate GRUB
> configuration
> -* grub-mkpasswd-pbkdf2: (grub)Invoking grub-mkpasswd-pbkdf2.
> -* grub-mkrelpath: (grub)Invoking grub-mkrelpath.
> -* grub-mkrescue: (grub)Invoking grub-mkrescue.  Make a GRUB rescue image
> -* grub-mount: (grub)Invoking grub-mount.Mount a file system using
> GRUB
> -* grub-probe: (grub)Invoking grub-probe.Probe device information
> -* grub-script-check: (grub)Invoking grub-script-check.
> +* GRUB2: (grub2). The GRand Unified Bootloader
> +* grub2-install: (grub2)Invoking grub2-install.Install GRUB on your
> drive
> +* grub2-mkconfig: (grub2)Invoking grub2-mkconfig.  Generate GRUB
> configuration
> +* grub2-mkpasswd-pbkdf2: (grub2)Invoking grub2-mkpasswd-pbkdf2.
> +* grub2-mkrelpath: (grub2)Invoking grub2-mkrelpath.
> +* grub2-mkrescue: (grub2)Invoking grub2-mkrescue.  Make a GRUB rescue
> image
> +* grub2-mount: (grub2)Invoking grub2-mount.Mount a file system
> using GRUB
> +* grub2-probe: (grub2)Invoking grub2-probe.Probe device
> information
> +* grub2-script-check: (grub2)Invoking grub2-script-check.
>  @end direntry
>
>  @setchapternewpage odd
> @@ -223,7 +223,7 @@ surprising.
>
>  @item
>  @file{grub.cfg} is typically automatically generated by
> -@command{grub-mkconfig} (@pxref{Simple configuration}).  This makes it
> +@command{grub2-mkconfig} (@pxref{Simple configuration}).  This makes it
>  easier to handle versioned kernel upgrades.
>
>  @item
> @@ -237,7 +237,7 @@ scripting language: variables, conditionals, and loops
> are available.
>  @item
>  A small amount of persistent storage is available across reboots, using
> the
>  @command{save_env} and @command{load_env} commands in GRUB and the
> -@command{grub-editenv} utility.  This is not available in all
> configurations
> +@command{grub2-editenv} utility.  This is not available in all
> configurations
>  (@pxref{Environment block}).
>
>  @item
> @@ -542,7 +542,7 @@ On OS which have device nodes similar to Unix-like OS
> GRUB tools use the
>  OS name. E.g. for GNU/Linux:
>
>  @example
> -# @kbd{grub-install /dev/sda}
> +# @kbd{grub2-install /dev/sda}
>  @end example
>
>  On AROS we use another syntax. For volumes:
> @@ -565,7 +565,7 @@ For disks we use syntax:
>  E.g.
>
>  @example
> -# @kbd{grub-install //:ata.device/0/0}
> +# @kbd{grub2-install //:ata.device/0/0}
>  @end example
>
>  On Windows we use UNC path. For volumes it's typically
> @@ -592,7 +592,7 @@ For disks it's
>  E.g.
>
>  @example
> -# @kbd{grub-install \\?\PhysicalDrive0}
> +# @kbd{grub2-install \\?\PhysicalDrive0}
>  @end example
>
>  Beware that you may need to further escape the backslashes depending on
> your
> @@ -602,7 +602,7 @@ When compiled with cygwin support then cygwin drive
> names are automatically
>  when needed. E.g.
>
>  @example
> -# @kbd{grub-install /dev/sda}
> +# @kbd{grub2-install /dev/sda}
>  @end example
>
>  @node Installation
> @@ -615,7 +615,7 @@ from the source tarball, or as a package for your OS.
>
>  After you have done that, you need to install the boot loader on a
>  drive (floppy or hard disk) by using the utility
> -@command{grub-install} (@pxref{Invoking grub-install}) on a UNIX

Re: [PATCH v1 33/37] btrfs: grub2-btrfs-06-subvol-mount

[Vladimir 'phcoder' Serbinenko]

What do you try to achieve with this that can't be achieved with using full
path? We should avoid using hidden state for directory parsing. Solaris
GRUB legacy used it for ZFS and it was a mess.

Le lun. 7 oct. 2024, 21:22, Leo Sandoval  a écrit :

> From: Michael Chang 
>
> Signed-off-by: Michael Chang 
> Signed-off-by: Robbie Harwood 
> ---
>  grub-core/fs/btrfs.c| 195 +++-
>  grub-core/osdep/linux/getroot.c | 148 +++-
>  include/grub/emu/getroot.h  |   5 +
>  util/grub-install.c |  49 
>  4 files changed, 392 insertions(+), 5 deletions(-)
>
> diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
> index d47f9ab03..d44a1c73b 100644
> --- a/grub-core/fs/btrfs.c
> +++ b/grub-core/fs/btrfs.c
> @@ -41,6 +41,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -266,6 +267,12 @@ static grub_err_t
>  grub_btrfs_read_logical (struct grub_btrfs_data *data,
>  grub_disk_addr_t addr, void *buf, grub_size_t
> size,
>  int recursion_depth);
> +static grub_err_t
> +get_root (struct grub_btrfs_data *data, struct grub_btrfs_key *key,
> + grub_uint64_t *tree, grub_uint8_t *type);
> +
> +grub_uint64_t
> +find_mtab_subvol_tree (const char *path, char **path_in_subvol);
>
>  static grub_err_t
>  read_sblock (grub_disk_t disk, struct grub_btrfs_superblock *sb)
> @@ -1302,9 +1309,26 @@ lookup_root_by_name(struct grub_btrfs_data *data,
> const char *path)
>grub_err_t err;
>grub_uint64_t tree = 0;
>grub_uint8_t type;
> +  grub_uint64_t saved_tree;
>struct grub_btrfs_key key;
>
> +  if (path[0] == '\0')
> +{
> +  data->fs_tree = 0;
> +  return GRUB_ERR_NONE;
> +}
> +
> +  err = get_root (data, &key, &tree, &type);
> +  if (err)
> +return err;
> +
> +  saved_tree = data->fs_tree;
> +  data->fs_tree = tree;
> +
>err = find_path (data, path, &key, &tree, &type);
> +
> +  data->fs_tree = saved_tree;
> +
>if (err)
>return grub_error(GRUB_ERR_FILE_NOT_FOUND, "couldn't locate %s\n",
> path);
>
> @@ -2316,11 +2340,20 @@ grub_btrfs_dir (grub_device_t device, const char
> *path,
>grub_uint64_t tree;
>grub_uint8_t type;
>grub_size_t est_size = 0;
> +  char *new_path = NULL;
>
>if (!data)
>  return grub_errno;
>
> -  err = find_path (data, path, &key_in, &tree, &type);
> +  tree = find_mtab_subvol_tree (path, &new_path);
> +
> +  if (tree)
> +data->fs_tree = tree;
> +
> +  err = find_path (data, new_path ? new_path : path, &key_in, &tree,
> &type);
> +  if (new_path)
> +grub_free (new_path);
> +
>if (err)
>  {
>grub_btrfs_unmount (data);
> @@ -2447,11 +2480,21 @@ grub_btrfs_open (struct grub_file *file, const
> char *name)
>struct grub_btrfs_inode inode;
>grub_uint8_t type;
>struct grub_btrfs_key key_in;
> +  grub_uint64_t tree;
> +  char *new_path = NULL;
>
>if (!data)
>  return grub_errno;
>
> -  err = find_path (data, name, &key_in, &data->tree, &type);
> +  tree = find_mtab_subvol_tree (name, &new_path);
> +
> +  if (tree)
> +data->fs_tree = tree;
> +
> +  err = find_path (data, new_path ? new_path : name, &key_in,
> &data->tree, &type);
> +  if (new_path)
> +grub_free (new_path);
> +
>if (err)
>  {
>grub_btrfs_unmount (data);
> @@ -2686,6 +2729,150 @@ grub_cmd_btrfs_info (grub_command_t cmd
> __attribute__ ((unused)), int argc,
>return 0;
>  }
>
> +struct grub_btrfs_mtab
> +{
> +  struct grub_btrfs_mtab *next;
> +  struct grub_btrfs_mtab **prev;
> +  char *path;
> +  char *subvol;
> +  grub_uint64_t tree;
> +};
> +
> +typedef struct grub_btrfs_mtab* grub_btrfs_mtab_t;
> +
> +static struct grub_btrfs_mtab *btrfs_mtab;
> +
> +#define FOR_GRUB_MTAB(var) FOR_LIST_ELEMENTS (var, btrfs_mtab)
> +#define FOR_GRUB_MTAB_SAFE(var, next) FOR_LIST_ELEMENTS_SAFE((var),
> (next), btrfs_mtab)
> +
> +static void
> +add_mountpoint (const char *path, const char *subvol, grub_uint64_t tree)
> +{
> +  grub_btrfs_mtab_t m = grub_malloc (sizeof (*m));
> +
> +  m->path = grub_strdup (path);
> +  m->subvol = grub_strdup (subvol);
> +  m->tree = tree;
> +  grub_list_push (GRUB_AS_LIST_P (&btrfs_mtab), GRUB_AS_LIST (m));
> +}
> +
> +static grub_err_t
> +grub_cmd_btrfs_mount_subvol (grub_command_t cmd __attribute__ ((unused)),
> int argc,
> +char **argv)
> +{
> +  char *devname, *dirname, *subvol;
> +  struct grub_btrfs_key key_in;
> +  grub_uint8_t type;
> +  grub_uint64_t tree;
> +  grub_uint64_t saved_tree;
> +  grub_err_t err;
> +  struct grub_btrfs_data *data = NULL;
> +  grub_device_t dev = NULL;
> +
> +  if (argc < 3)
> +return grub_error (GRUB_ERR_BAD_ARGUMENT, "required   and
> ");
> +
> +  devname = grub_file_get_device_name(argv[0]);
> +  dev = grub_device_open (devname);
> +  grub_free (devname);
> +
> +  if (!dev)
> +{
> +  err = grub_errno;
> +  goto err_out;
> +}
> +
> +  dirname