Re: [PATCH] cli_lock: Added build option to block command line interface

2024-01-25 Thread Vladimir 'phcoder' Serbinenko
Please detail your use case. GRUB already had user framework in the same
problem space.

Le mer. 24 janv. 2024, 09:27, Alec Brown  a écrit :

> Added functionality to disable command line interface access and editing
> of GRUB
> menu entries if GRUB image is built with --disable-cli.
>
> Signed-off-by: Alec Brown 
> ---
>  docs/grub.texi |  6 --
>  grub-core/kern/main.c  | 28 
>  grub-core/kern/rescue_reader.c | 13 +
>  grub-core/normal/auth.c|  3 +++
>  grub-core/normal/menu_text.c   | 31 +--
>  include/grub/kernel.h  |  3 ++-
>  include/grub/misc.h|  2 ++
>  include/grub/util/install.h|  8 ++--
>  util/grub-install-common.c | 11 ---
>  util/grub-mkimage.c|  9 -
>  util/mkimage.c | 16 +++-
>  11 files changed, 106 insertions(+), 24 deletions(-)
>
> diff --git a/docs/grub.texi b/docs/grub.texi
> index a225f9a88..96ab17d5b 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -6412,8 +6412,10 @@ the GRUB command line, edit menu entries, and
> execute any menu entry.  If
>  @samp{superusers} is set, then use of the command line and editing of menu
>  entries are automatically restricted to superusers. Setting
> @samp{superusers}
>  to empty string effectively disables both access to CLI and editing of
> menu
> -entries. Note: The environment variable needs to be exported to also
> affect
> -the section defined by the @samp{submenu} command (@pxref{submenu}).
> +entries. Building a grub image with @samp{--disable-cli} option will also
> +disable access to CLI and editing of menu entries, as well as disabling
> rescue
> +mode. Note: The environment variable needs to be exported to also affect
> the
> +section defined by the @samp{submenu} command (@pxref{submenu}).
>
>  Other users may be allowed to execute specific menu entries by giving a
> list of
>  usernames (as above) using the @option{--users} option to the
> diff --git a/grub-core/kern/main.c b/grub-core/kern/main.c
> index 731c07c29..30643164e 100644
> --- a/grub-core/kern/main.c
> +++ b/grub-core/kern/main.c
> @@ -30,11 +30,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #ifdef GRUB_MACHINE_PCBIOS
>  #include 
>  #endif
>
> +static bool cli_disabled = false;
> +
>  grub_addr_t
>  grub_modules_get_end (void)
>  {
> @@ -237,6 +240,28 @@ grub_load_normal_mode (void)
>grub_command_execute ("normal", 0, 0);
>  }
>
> +bool
> +grub_is_cli_disabled (void)
> +{
> +  return cli_disabled;
> +}
> +
> +static void
> +check_is_cli_disabled (void)
> +{
> +  struct grub_module_header *header;
> +  header = 0;
> +
> +  FOR_MODULES (header)
> +{
> +  if (header->type == OBJ_TYPE_DISABLE_CLI)
> +   {
> + cli_disabled = true;
> + return;
> +   }
> +}
> +}
> +
>  static void
>  reclaim_module_space (void)
>  {
> @@ -294,6 +319,9 @@ grub_main (void)
>
>grub_boot_time ("After loading embedded modules.");
>
> +  /* Check if the CLI should be disabled */
> +  check_is_cli_disabled ();
> +
>/* It is better to set the root device as soon as possible,
>   for convenience.  */
>grub_set_prefix_and_root ();
> diff --git a/grub-core/kern/rescue_reader.c
> b/grub-core/kern/rescue_reader.c
> index dcd7d4439..4259857ba 100644
> --- a/grub-core/kern/rescue_reader.c
> +++ b/grub-core/kern/rescue_reader.c
> @@ -78,6 +78,19 @@ grub_rescue_read_line (char **line, int cont,
>  void __attribute__ ((noreturn))
>  grub_rescue_run (void)
>  {
> +  /* Stall if the CLI has been disabled */
> +  if (grub_is_cli_disabled ())
> +{
> +  grub_printf ("Rescue mode has been disabled...\n");
> +
> +  do
> +   {
> + /* Do not optimize out the loop. */
> + asm volatile ("");
> +   }
> +  while (1);
> +}
> +
>grub_printf ("Entering rescue mode...\n");
>
>while (1)
> diff --git a/grub-core/normal/auth.c b/grub-core/normal/auth.c
> index 517fc623f..d94020186 100644
> --- a/grub-core/normal/auth.c
> +++ b/grub-core/normal/auth.c
> @@ -209,6 +209,9 @@ grub_auth_check_authentication (const char *userlist)
>char entered[GRUB_AUTH_MAX_PASSLEN];
>struct grub_auth_user *user;
>
> +  if (grub_is_cli_disabled ())
> +return GRUB_ACCESS_DENIED;
> +
>grub_memset (login, 0, sizeof (login));
>
>if (is_authenticated (userlist))
> diff --git a/grub-core/normal/menu_text.c b/grub-core/normal/menu_text.c
> index b1321eb26..9c383e64a 100644
> --- a/grub-core/normal/menu_text.c
> +++ b/grub-core/normal/menu_text.c
> @@ -178,21 +178,24 @@ command-line or ESC to discard edits and return to
> the GRUB menu."),
>
>grub_free (msg_translated);
>
> -  if (nested)
> +  if (!grub_is_cli_disabled ())
> {
> - ret += grub_print_message_indented_real
> -   (_("Press enter to boot the selected OS, "
> -  "`e' to edit the commands before booting "
> -

Re: [PATCH 2/3] osdep/unix/getroot.c: Clean up redundant code

2024-01-25 Thread Vladimir 'phcoder' Serbinenko
Le mar. 23 janv. 2024, 17:44, Daniel Kiper  a écrit :

> Mate,
>
> Next time please respond to all people/addresses in the original
> email...
>
> On Mon, Jan 22, 2024 at 02:09:38PM +, Mate Kukri wrote:
> > Dear Alec, and grub-devel,
> >
> > I haven't checked the specific code in question, but do we really want
> > to be removing such null-assignments? (Thinking about multiple patches
> > exactly like this).
> >
> > In correct code, they are of course redundant by definition, however
> > their intended purpose is that if the code happens to be incorrect,
> > they turn use-after-free bugs into zero page accesses.
> >
> > Since static analysis of a language like C is inherently conservative,
> > it is entirely possible that it is detecting the redundant assignment,
> > but not the use after free it would have prevented.
>
> We know the Coverity makes mistakes. So, we carefully check its reports.
> These ones are not exceptions. Here the Coverity is correct and it is
> safe to remove redundant code. I expect somebody was changing the code
> at some point and forgot to drop surplus assignments.
>
Nope. It was to keep an invariant and ensure we don't double-free
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: [PATCH 0/3] Clean up unused values

2024-01-25 Thread Vladimir 'phcoder' Serbinenko
I oppose to all 3 patches. These assignments are not redundant but keep an
important invariant: the variable in question can be passed to free().
For this it needs to either be NULL or point to a valid allocated memory.
In this code this ensures that we never double free even after code changes

Le sam. 20 janv. 2024, 05:53, Alec Brown  a écrit :

> Coverity listed three unused value bugs in the GRUB. These patches help
> clean
> up and remove these uneccessary bits of code.
>
> The Coverity bugs being addressed are:
> CID 428875
> CID 428876
> CID 428877
>
> Alec Brown (3):
>   fs/jfs.c: Clean up redundant code
>   osdep/unix/getroot.c: Clean up redundant code
>   loader/i386/multiboot_mbi.c: Clean up redundant code
>
>  grub-core/fs/jfs.c| 1 -
>  grub-core/loader/i386/multiboot_mbi.c | 2 +-
>  grub-core/osdep/unix/getroot.c| 1 -
>  3 files changed, 1 insertion(+), 3 deletions(-)
>
>
>
> ___
> 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: State of Argon2 support

2024-01-25 Thread Daniel Kiper
Adding Vladimir who knows GRUB history better than I...

On Wed, Jan 24, 2024 at 01:23:55AM -0500, Nikolaos Chatzikonstantinou wrote:

[...]

> My apologies for the repeated messages, but I came up with just one
> more question that I'm curious about. To summarize my questions:
>
> 1. Where is the libgcrypt bundle from grub from? I think my
> investigation has led me around version 1.7.0 of libgcrypt, but if I
> can get a precise commit or version, that would be useful.
>
> ... and now to my new question:

Vladimir, could you help with that?

> 2. What is the reason libgcrypt is bundled as opposed to a regular dependency?

I am not entirely sure I understand the question. Could you elaborate?

Daniel

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


Re: [PATCHv2] hurd: Find proper ld.so on 64-bit systems

2024-01-25 Thread Daniel Kiper
On Tue, Jan 23, 2024 at 09:47:56PM +0100, Samuel Thibault wrote:
> The 64bit ABI defines ld.so to be /lib/ld-x86-64.so.1
>
> Signed-off-by: Samuel Thibault 

Reviewed-by: Daniel Kiper 

Daniel

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


Re: [PATCHv2] osdep/hurd/getroot: Fix 64bit build

2024-01-25 Thread Daniel Kiper
On Tue, Jan 23, 2024 at 09:47:36PM +0100, Samuel Thibault wrote:
> file_get_fs_options takes a mach_msg_type_number_t (32 bit), not a size_t
> (64 bit on 64-bit platforms).
>
> Signed-off-by: Samuel Thibault 

Reviewed-by: Daniel Kiper 

Daniel

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