Re: [PATCH] grub-core/Makefile.am: Make path to extra_deps.lst relative to $(top_srcdir)/grub-core
Quoting Mate Kukri (2023-12-08 18:20:12) > 154dcb1aea9f8fc42b2bce98bebed004d7783a7d broke out of tree builds by > introducing the extra_deps.lst file into the source tree but referencing > it just by name in grub-core/Makefile.am. > > Signed-off-by: Mate Kukri > --- > grub-core/Makefile.am | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/grub-core/Makefile.am b/grub-core/Makefile.am > index a48ce37b4..f18550c1c 100644 > --- a/grub-core/Makefile.am > +++ b/grub-core/Makefile.am > @@ -454,8 +454,8 @@ crypto.lst: $(srcdir)/lib/libgcrypt-grub/cipher/crypto.lst > platform_DATA += crypto.lst > CLEANFILES += crypto.lst > > -syminfo.lst: gensyminfo.sh kernel_syms.lst extra_deps.lst $(MODULE_FILES) > - cat kernel_syms.lst extra_deps.lst > $@.new > +syminfo.lst: gensyminfo.sh kernel_syms.lst > $(top_srcdir)/grub-core/extra_deps.lst $(MODULE_FILES) > + cat kernel_syms.lst $(top_srcdir)/grub-core/extra_deps.lst > $@.new > for m in $(MODULE_FILES); do \ > sh $< $$m >> $@.new || exit 1; \ > done > -- > 2.39.2 Looks good to me. Thank you for posting this. -Oliver ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 1/3] Allow explicit module dependencies
Quoting Julian Andres Klode (2023-12-08 18:29:52) > On Fri, Dec 08, 2023 at 01:20:37PM +0100, Daniel Kiper wrote: > > On Wed, Dec 06, 2023 at 05:39:53PM +0100, Daniel Kiper wrote: > > > On Wed, Dec 06, 2023 at 04:39:29PM +0100, Olaf Hering wrote: > > > > Wed, 6 Dec 2023 16:24:53 +0100 Daniel Kiper : > > > > > > > > > Could you provide us exact steps to reproduce the problem? > > > > > > > > Something like this? > > > > > > > > mkdir .b > > > > cd $_ > > > > ../grub-src-dir/configure [options] > > > > > > Ugh, yeah, the file is missing in this case. Oliver, could you fix that? > > > > > > > A brief look at the sources indicates the new file could be generated > > > > during build, with "echo content > $@". > > > > > > Or copy original file... But generation can be a bit more universal... > > > > Oliver, ping? > > > > I really want to cut release next week and this is a blocker... > > Mate just posted > > [PATCH] grub-core/Makefile.am: Make path to extra_deps.lst relative to > $(top_srcdir)/grub-core > > which should resolve this issue. > Sorry for the late reply, I was away. -Oliver ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] commands/acpi: Fix furthering address the tables based upon the Entry field of XSDT
According to the ACPI specification, the Entry field of XSDT containsts an
array of 64-bit physical addresses that point to other DESCRIPTION_HEADERs.
But entry_ptr is defined as a 32-bit pointer, which result in mistakenly
treating each 64-bit length address as two 32-bit length addresses when
iterating through the Entry field of XSDT.
Fix the issue by using the correct address length during the iteration process.
Signed-off-by: Qiumiao Zhang
---
grub-core/commands/acpi.c | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/grub-core/commands/acpi.c b/grub-core/commands/acpi.c
index 1c034463c..12b4a84eb 100644
--- a/grub-core/commands/acpi.c
+++ b/grub-core/commands/acpi.c
@@ -490,12 +490,12 @@ grub_cmd_acpi (struct grub_extcmd_context *ctxt, int
argc, char **args)
if (rsdp)
{
- grub_uint32_t *entry_ptr;
+ grub_uint8_t *entry_ptr;
char *exclude = 0;
char *load_only = 0;
char *ptr;
- /* RSDT consists of header and an array of 32-bit pointers. */
- struct grub_acpi_table_header *rsdt;
+ int offset = 0;
+ struct grub_acpi_table_header *table_head;
exclude = state[0].set ? grub_strdup (state[0].arg) : 0;
if (exclude)
@@ -515,20 +515,32 @@ grub_cmd_acpi (struct grub_extcmd_context *ctxt, int
argc, char **args)
rev1 = ! rsdp->revision;
rev2 = rsdp->revision;
if (rev2 && ((struct grub_acpi_table_header *) (grub_addr_t) ((struct
grub_acpi_rsdp_v20 *) rsdp)->xsdt_addr) != NULL)
- rsdt = (struct grub_acpi_table_header *) (grub_addr_t) ((struct
grub_acpi_rsdp_v20 *) rsdp)->xsdt_addr;
+ {
+ /* XSDT consists of header and an array of 64-bit pointers. */
+ table_head = (struct grub_acpi_table_header *) (grub_addr_t) ((struct
grub_acpi_rsdp_v20 *) rsdp)->xsdt_addr;
+ offset = sizeof(((struct grub_acpi_rsdp_v20 *) rsdp)->xsdt_addr);
+ }
else
- rsdt = (struct grub_acpi_table_header *) (grub_addr_t) rsdp->rsdt_addr;
+ {
+ /* RSDT consists of header and an array of 32-bit pointers. */
+ table_head = (struct grub_acpi_table_header *) (grub_addr_t)
rsdp->rsdt_addr;
+ offset = sizeof(rsdp->rsdt_addr);
+ }
/* Load host tables. */
- for (entry_ptr = (grub_uint32_t *) (rsdt + 1);
- entry_ptr < (grub_uint32_t *) (((grub_uint8_t *) rsdt)
- + rsdt->length);
- entry_ptr++)
+ for (entry_ptr = (grub_uint8_t *) (table_head + 1);
+ entry_ptr < (grub_uint8_t *) (((grub_uint8_t *) table_head)
+ + table_head->length);
+ entry_ptr += offset)
{
char signature[5];
struct efiemu_acpi_table *table;
- struct grub_acpi_table_header *curtable
- = (struct grub_acpi_table_header *) (grub_addr_t) *entry_ptr;
+ struct grub_acpi_table_header *curtable;
+ if (offset == sizeof(rsdp->rsdt_addr))
+ curtable = (struct grub_acpi_table_header *) (grub_addr_t)
*((grub_uint32_t *)entry_ptr);
+ else
+ curtable = (struct grub_acpi_table_header *) (grub_addr_t)
*((grub_uint64_t *)entry_ptr);
+
signature[4] = 0;
for (i = 0; i < 4;i++)
signature[i] = grub_tolower (curtable->signature[i]);
--
2.28.0.windows.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] grub-install: Move platdir path canonicalization after files were copied to grubdir
On Fri, Dec 08, 2023 at 04:57:55PM +, Mate Kukri wrote: > The previous grub-install patch delaying the copying of files caused a > regression when installing without an existing directory structure. > > This patch ensures that the platform directory actually exists by the > time the code tries to canonicalize its filename. > > Signed-off-by: Mate Kukri Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] grub-core/Makefile.am: Make path to extra_deps.lst relative to $(top_srcdir)/grub-core
On Mon, Dec 11, 2023 at 12:23:05AM -0800, Oliver Steffen wrote: > Quoting Mate Kukri (2023-12-08 18:20:12) > > 154dcb1aea9f8fc42b2bce98bebed004d7783a7d broke out of tree builds by > > introducing the extra_deps.lst file into the source tree but referencing > > it just by name in grub-core/Makefile.am. > > > > Signed-off-by: Mate Kukri > > --- > > grub-core/Makefile.am | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/grub-core/Makefile.am b/grub-core/Makefile.am > > index a48ce37b4..f18550c1c 100644 > > --- a/grub-core/Makefile.am > > +++ b/grub-core/Makefile.am > > @@ -454,8 +454,8 @@ crypto.lst: > > $(srcdir)/lib/libgcrypt-grub/cipher/crypto.lst > > platform_DATA += crypto.lst > > CLEANFILES += crypto.lst > > > > -syminfo.lst: gensyminfo.sh kernel_syms.lst extra_deps.lst $(MODULE_FILES) > > - cat kernel_syms.lst extra_deps.lst > $@.new > > +syminfo.lst: gensyminfo.sh kernel_syms.lst > > $(top_srcdir)/grub-core/extra_deps.lst $(MODULE_FILES) > > + cat kernel_syms.lst $(top_srcdir)/grub-core/extra_deps.lst > $@.new > > for m in $(MODULE_FILES); do \ > > sh $< $$m >> $@.new || exit 1; \ > > done > > -- > > 2.39.2 > > Looks good to me. Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Improving grub-mkstandalone for reproducible build
On Wed, Dec 06, 2023 at 11:42:02AM +0800, Michael Chang via Grub-devel wrote: > Enclosed is the description from openSUSE bugzilla entry: > > While working on reproducible builds for openSUSE, I found that our > grub2 package's /usr/share/grub2/x86_64-xen/grub.xen varies across > builds. > > I identified 2 issues: The tar contains changing (octal) mtime values. > The tar stores files in random filesystem readdir order. > > The first issue produces such diffs: > --- old /usr/share/grub2/x86_64-xen/grub.xen (objdump) > +++ new /usr/share/grub2/x86_64-xen/grub.xen (objdump) > @@ -4896,7 +4896,7 @@ > 01319f 30303030 36303000 30303031 600.0001 > 0131af 37353000 30303031 37353000 30303030 750.0001750. > 0131bf 30303033 34353000 31343533 31323035 0003450.14531205 > - 0131cf 35303300 30303135 30313320 3000 503.0015013 0... > + 0131cf 36313200 30303135 30313420 3000 612.0015014 0... > 0131df > 0131ef > > > and the second issue produced this diff: > 01311f 0100 > 01312f 0100 08b42600 ..&. > 01313f 626f6f74 2f677275 622f7838 365f3634 boot/grub/x86_64 > - 01314f 2d78656e 2f646973 6b2e6d6f 6400 -xen/disk.mod... > + 01314f 2d78656e 2f6c7378 656e2e6d 6f64 -xen/lsxen.mod.. > 01315f > > The second issue probably comes from grub_util_fd_readdir that would > need to collect+sort entries before further processing. > > Furthermore, both patches were developed to address the aforementioned > issues individually. We hope to contribute them to upstream if the > enhancement sounds appealing to others as well. > > Thanks. > > Michael Chang (2): > mkstandalone: ensure stable timestamps for generated images > mkstandalone: ensure deterministic tar file creation by sorting > contents For both patches Reviewed-by: Daniel Kiper ... Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 2/3] efi: Generate stack protector canary at build time if urandom is available
Generating the canary at build time allows the canary to be different for
every build which could limit the effectiveness of certain exploits.
Fallback to the statically generated random bytes if /dev/urandom is not
readable (eg. Windows).
Reduce the canary to 3 bytes with a NULL upper byte on 32-bit architectures,
which use a 32-bit canary, to filter out string buffer overflow attacks.
Signed-off-by: Glenn Washburn
---
config.h.in | 2 ++
configure.ac | 20
grub-core/kern/efi/init.c | 2 +-
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/config.h.in b/config.h.in
index 4d1e50eba79c..9b1d39971858 100644
--- a/config.h.in
+++ b/config.h.in
@@ -64,6 +64,8 @@
# define GRUB_TARGET_CPU "@GRUB_TARGET_CPU@"
# define GRUB_PLATFORM "@GRUB_PLATFORM@"
+# define GRUB_STACK_PROTECTOR_INIT @GRUB_STACK_PROTECTOR_INIT@
+
# define RE_ENABLE_I18N 1
# define _GNU_SOURCE 1
diff --git a/configure.ac b/configure.ac
index c19779c14d08..788f5f3206f1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1438,6 +1438,26 @@ else
AC_MSG_ERROR([invalid value $enable_stack_protector for
--enable-stack-protector])
fi
TARGET_CPPFLAGS="$TARGET_CPPFLAGS -DGRUB_STACK_PROTECTOR=1"
+
+ if test -r /dev/urandom; then
+ # Generate the 8 byte stack protector canary at build time if /dev/urandom
+ # is able to be read. The first byte should be NULL to filter out string
+ # buffer overflow attacks.
+ GRUB_STACK_PROTECTOR_INIT="$($PYTHON -c 'import codecs;
rf=open("/dev/urandom", "rb"); print("0x00"+codecs.encode(rf.read(7),
"hex").decode("ascii"))')"
+ else
+# Some hosts may not have a urandom (eg. Windows), so use statically
+# generated random bytes
+GRUB_STACK_PROTECTOR_INIT="0x00f2b7e2f193b25c"
+ fi
+
+ if test x"$target_m32" = x1 ; then
+# Make sure that the canary default value is 24-bits by only using the
+# lower 3 bytes on 32 bit systems. This allows the upper byte to be NULL
+# to filter out string buffer overflow attacks.
+GRUB_STACK_PROTECTOR_INIT="0x00$(echo "$GRUB_STACK_PROTECTOR_INIT" | sed
's/.*\(..\)$/\1/')"
+ fi
+
+ AC_SUBST([GRUB_STACK_PROTECTOR_INIT])
fi
CFLAGS="$TARGET_CFLAGS"
diff --git a/grub-core/kern/efi/init.c b/grub-core/kern/efi/init.c
index 08e24d46fad9..6c54af6e79e5 100644
--- a/grub-core/kern/efi/init.c
+++ b/grub-core/kern/efi/init.c
@@ -46,7 +46,7 @@ static grub_guid_t rng_protocol_guid =
GRUB_EFI_RNG_PROTOCOL_GUID;
static grub_efi_uint8_t stack_chk_guard_buf[32];
/* Initialize canary in case there is no RNG protocol. */
-grub_addr_t __stack_chk_guard = (grub_addr_t) 0x00f2b7e2f193b25c;
+grub_addr_t __stack_chk_guard = (grub_addr_t) GRUB_STACK_PROTECTOR_INIT;
void __attribute__ ((noreturn))
__stack_chk_fail (void)
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 0/3] efi: Initialize canary to non-zero value
This series extends and improves the previous patch initializing the stack guard canary. The first patch improves the previous patch by setting the most significant byte to NULL, which will filter out string buffer overflow attacks. The second patch allows creation of the canary at build time from urandom if it exists. This change breaks reproducible builds, so the third patch allows the canary to be set from the environment variable SOURCE_DATE_EPOCH if its value is not empty. Glenn Glenn Washburn (3): efi: Initialize canary to non-zero value efi: Generate stack protector canary at build time if urandom is available efi: Add support for reproducible builds config.h.in | 2 ++ configure.ac | 22 ++ grub-core/kern/efi/init.c | 3 ++- 3 files changed, 26 insertions(+), 1 deletion(-) -- 2.34.1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 3/3] efi: Add support for reproducible builds
Having randomly generated bytes in the binary output breaks reproducible builds. Since build timestamps are usually the source of irreproducibility there is a standard which defines an environment variable SOURCE_DATE_EPOCH to be used when set for build timestamps. According to the standard[1], the value of SOURCE_DATE_EPOCH is a base-10 integer of the number of seconds since the UNIX epoch. Currently, this is a 10 digit number that fits into 32-bits, but will not shortly after the year 2100. So to be future-proof only use the least significant 32-bits. On 64-bit architectures, where the canary is also 64-bits, there is an extra 32-bits that can be filled to provide more entropy. The first byte is null to filter out string buffer overflow attacks and the remaining 24-bits are set to static random bytes. [1] https://reproducible-builds.org/specs/source-date-epoch Signed-off-by: Glenn Washburn --- configure.ac | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 788f5f3206f1..3d326b8725f2 100644 --- a/configure.ac +++ b/configure.ac @@ -1439,7 +1439,9 @@ else fi TARGET_CPPFLAGS="$TARGET_CPPFLAGS -DGRUB_STACK_PROTECTOR=1" - if test -r /dev/urandom; then + if test -n "$SOURCE_DATE_EPOCH"; then + GRUB_STACK_PROTECTOR_INIT="0x00f2b7e2$(printf "%x" "$SOURCE_DATE_EPOCH" | sed 's/.*\(\)$/\1/')" + elif test -r /dev/urandom; then # Generate the 8 byte stack protector canary at build time if /dev/urandom # is able to be read. The first byte should be NULL to filter out string # buffer overflow attacks. -- 2.34.1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 1/3] efi: Initialize canary to non-zero value
The canary, __stack_chk_guard, is in the BSS and so will get initialized to zero if it is not explicitly initialized. If the UEFI firmware does not support the RNG protocol, then the canary will not be randomized and will be zero. This seems like a possibly easier value to write by an attacker. Initialize canary to static random bytes, so that it is still random when there is no RNG protocol. Set at least one byte to NULL to protect against string buffer overflow attacks. Signed-off-by: Glenn Washburn --- grub-core/kern/efi/init.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/grub-core/kern/efi/init.c b/grub-core/kern/efi/init.c index e759cc315b85..08e24d46fad9 100644 --- a/grub-core/kern/efi/init.c +++ b/grub-core/kern/efi/init.c @@ -45,7 +45,8 @@ static grub_guid_t rng_protocol_guid = GRUB_EFI_RNG_PROTOCOL_GUID; */ static grub_efi_uint8_t stack_chk_guard_buf[32]; -grub_addr_t __stack_chk_guard; +/* Initialize canary in case there is no RNG protocol. */ +grub_addr_t __stack_chk_guard = (grub_addr_t) 0x00f2b7e2f193b25c; void __attribute__ ((noreturn)) __stack_chk_fail (void) -- 2.34.1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 00/14] Fix compilation on *BSD platforms
On Sun, Dec 10, 2023 at 11:47:07PM +0100, Vladimir 'phcoder' Serbinenko wrote: > This patch series fixes compilation problems and one boot bug for different > BSD > platforms. Mostly they are safe and touch files which are not used by Linux For all patches Reviewed-by: Daniel Kiper ... I will push your patches together with other ones tomorrow or on Wednesday. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] commands/acpi: Fix furthering address the tables based upon the Entry field of XSDT
On Mon, Dec 11, 2023 at 05:20:25PM +0800, Qiumiao Zhang via Grub-devel wrote: > According to the ACPI specification, the Entry field of XSDT containsts an > array of 64-bit physical addresses that point to other DESCRIPTION_HEADERs. > But entry_ptr is defined as a 32-bit pointer, which result in mistakenly > treating each 64-bit length address as two 32-bit length addresses when > iterating through the Entry field of XSDT. > > Fix the issue by using the correct address length during the iteration > process. > > Signed-off-by: Qiumiao Zhang Reviewed-by: Daniel Kiper but I will fix some minor things before push. This is an exception because it would be nice to have this patch in the release and we are behind the schedule. Next time I will ask you to do that... Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
