Re: State of Argon2 support
Le ven. 26 janv. 2024, 20:50, Daniel Kiper a écrit : > On Fri, Jan 26, 2024 at 03:18:57AM -0500, Nikolaos Chatzikonstantinou > wrote: > > On Thu, Jan 25, 2024 at 1:15 PM Daniel Kiper > wrote: > > > > > > 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? > > > > By bundling, I mean that someone copied libgcrypt files into the GRUB > project. > > > > To elaborate further, regular programs (not like GRUB which is a > > bootloader) can link statically or dynamically to libraries; but also, > > there's a third option, to dump the source code of a library directly > > into the source tree of the project. To my understanding this third > > option (which is not really a third linker option as it is not related > > to the linker) is chosen when the project needs to include its own > > patch set to the library. I am curious if GRUB has patched libgcrypt > > for some reason, and is that why libgcrypt is bundled with GRUB? > > I think Vladimir could tell us more here... > > Anyway, I think we should avoid patching libgcrypt, or any given library > merged with GRUB source, as much as possible. > This was my goal as well. Almost all the changes are difficult to avoid. But at least they are automated in most cases. See import_gcry script. I'm not on my computer now. I hope to find a time to have a look until the end of next week. > > Daniel > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] cli_lock: Added build option to block command line interface
Le ven. 26 janv. 2024, 23:15, Daniel Kiper a écrit : > On Fri, Jan 26, 2024 at 02:12:31AM +0300, Vladimir 'phcoder' Serbinenko > wrote: > > Please detail your use case. GRUB already had user framework in the same > > problem space. > > I am not sure what exactly you mean by "user framework". Could you > elaborate or point us code examples? > https://www.gnu.org/software/grub/manual/grub/grub.html#Authentication-and-authorisation > > Anyway, we need a mechanism to disallow access to CLI, arguments editing > for kernels, etc. I.e. user cannot change widely understood boot config > even being at the console. > Yes and it's exactly what happens as soon as superuser is set. Basically this patch is equivalent to having a superuser without a valid password. AFAIR it's achieved by setting superuser's but not issuing password commands. If not we can have password_deny command. > > Daniel > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] cli_lock: Added build option to block command line interface
On Fri, Jan 26, 2024 at 02:12:31AM +0300, Vladimir 'phcoder' Serbinenko wrote: > Please detail your use case. GRUB already had user framework in the same > problem space. I am not sure what exactly you mean by "user framework". Could you elaborate or point us code examples? Anyway, we need a mechanism to disallow access to CLI, arguments editing for kernels, etc. I.e. user cannot change widely understood boot config even being at the console. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] cli_lock: Added build option to block command line interface
On Wed, Jan 24, 2024 at 08:28:39AM +0100, Olaf Hering wrote: > Wed, 24 Jan 2024 06:26:37 + Alec Brown : > > > +static bool cli_disabled = false; > > Are there any other values than zero for "false"? > If not, the initialization can be removed. Even if you are technically correct I think we should not drop this initialization to make code clear at first glance. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: State of Argon2 support
On Fri, Jan 26, 2024 at 10:55:21AM +0100, Patrick Steinhardt wrote: > On Fri, Jan 26, 2024 at 03:18:57AM -0500, Nikolaos Chatzikonstantinou wrote: > > On Thu, Jan 25, 2024 at 1:15 PM Daniel Kiper wrote: > > > > > > 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? > > > > By bundling, I mean that someone copied libgcrypt files into the GRUB > > project. > > > > To elaborate further, regular programs (not like GRUB which is a > > bootloader) can link statically or dynamically to libraries; but also, > > there's a third option, to dump the source code of a library directly > > into the source tree of the project. To my understanding this third > > option (which is not really a third linker option as it is not related > > to the linker) is chosen when the project needs to include its own > > patch set to the library. I am curious if GRUB has patched libgcrypt > > for some reason, and is that why libgcrypt is bundled with GRUB? > > Yeah, the libgcrypt version carried by GRUB is heavily patched so that > it compiles within the non-libc environment that GRUB uses. That is the > whole crux of this topic -- if libgcrypt was simply a vanilla version > then it shouldn't be all that hard to update. > > I think in the long term it would be great indeed if we could refrain > from patching libgcrypt to the widest extent possible so that future > updates become easier. I guess that would require something of a "shim" > header that makes available all of the prerequisites that are currently > missing for libgcrypt to compile. I concur! However, it would be nice to have simple mechanism which allow us to disable unused features. I am not sure it will be possible without patching libgcrypt heavily. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: State of Argon2 support
On Fri, Jan 26, 2024 at 03:18:57AM -0500, Nikolaos Chatzikonstantinou wrote: > On Thu, Jan 25, 2024 at 1:15 PM Daniel Kiper wrote: > > > > 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? > > By bundling, I mean that someone copied libgcrypt files into the GRUB project. > > To elaborate further, regular programs (not like GRUB which is a > bootloader) can link statically or dynamically to libraries; but also, > there's a third option, to dump the source code of a library directly > into the source tree of the project. To my understanding this third > option (which is not really a third linker option as it is not related > to the linker) is chosen when the project needs to include its own > patch set to the library. I am curious if GRUB has patched libgcrypt > for some reason, and is that why libgcrypt is bundled with GRUB? I think Vladimir could tell us more here... Anyway, I think we should avoid patching libgcrypt, or any given library merged with GRUB source, as much as possible. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: State of Argon2 support
On Fri, Jan 26, 2024 at 03:18:57AM -0500, Nikolaos Chatzikonstantinou wrote: > On Thu, Jan 25, 2024 at 1:15 PM Daniel Kiper wrote: > > > > 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? > > By bundling, I mean that someone copied libgcrypt files into the GRUB project. > > To elaborate further, regular programs (not like GRUB which is a > bootloader) can link statically or dynamically to libraries; but also, > there's a third option, to dump the source code of a library directly > into the source tree of the project. To my understanding this third > option (which is not really a third linker option as it is not related > to the linker) is chosen when the project needs to include its own > patch set to the library. I am curious if GRUB has patched libgcrypt > for some reason, and is that why libgcrypt is bundled with GRUB? Yeah, the libgcrypt version carried by GRUB is heavily patched so that it compiles within the non-libc environment that GRUB uses. That is the whole crux of this topic -- if libgcrypt was simply a vanilla version then it shouldn't be all that hard to update. I think in the long term it would be great indeed if we could refrain from patching libgcrypt to the widest extent possible so that future updates become easier. I guess that would require something of a "shim" header that makes available all of the prerequisites that are currently missing for libgcrypt to compile. Patrick signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: State of Argon2 support
On Thu, Jan 25, 2024 at 1:15 PM Daniel Kiper wrote: > > 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? By bundling, I mean that someone copied libgcrypt files into the GRUB project. To elaborate further, regular programs (not like GRUB which is a bootloader) can link statically or dynamically to libraries; but also, there's a third option, to dump the source code of a library directly into the source tree of the project. To my understanding this third option (which is not really a third linker option as it is not related to the linker) is chosen when the project needs to include its own patch set to the library. I am curious if GRUB has patched libgcrypt for some reason, and is that why libgcrypt is bundled with GRUB? Regards, Nikolaos Chatzikonstantinou ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 0/3] Clean up unused values
If I may add a small point, apart from the invariant being kept, initializing on definition also makes bug behavior more deterministic. Hunting for a bug that only manifests on certain uninitialized values in memory is hard. On Thu, Jan 25, 2024 at 5:32 PM Vladimir 'phcoder' Serbinenko wrote: > > 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 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
