Re: [PATCH v3] docs: Add debugging chapter to development documentation
On Thu, Jun 15, 2023 at 13:06:09 +0200, Daniel Kiper wrote: > On Thu, Jun 15, 2023 at 01:21:57AM -0500, Oskari Pirhonen wrote: > > Oops, apologies for the late reply. Reading through it again, I found a > > few more small nits: > > Right now patch is in the git repo. If you want to improve that part of > doc please send a fix to grub-devel and CC interested folks. > > Daniel Can do. - Oskari signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 0/1] tpm: Enable boot despite unknown firmware failure
Hi all, This patch fixes small problem with my computer being unbootable under certain circumstances. It also addresses concerns pointed out by Daniel with previous version. If there are any, I would appreciate further comments. Best regards, Michał --- Changelog: v1->v2: - change grub_tpm_is_fail_fatal() back to tpm_is_fail_fatal() - make is_tpm_fail_fatal() static - move is_tpm_fail_fatal() body to include/grub/tpm.h - update docs excerpt about tpm_fail_fatal Michał Grzelak (1): tpm: Enable boot despite unknown firmware failure docs/grub.texi | 5 + grub-core/commands/efi/tpm.c | 3 ++- grub-core/commands/tpm.c | 7 --- include/grub/tpm.h | 9 + 4 files changed, 16 insertions(+), 8 deletions(-) -- 2.37.3 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 1/1] tpm: Enable boot despite unknown firmware failure
Currently booting the system is prevented when call to EFI firmware
hash_log_extend_event() returns unknown error. Solve this by following
convention used in commit a4356538d (commands/tpm: Don't propagate
measurement failures to the verifiers layer).
Let the system to be bootable by default when unknown TPM error is
encountered. Check environment variable tpm_fail_fatal to fallback to
previous behaviour.
Signed-off-by: Michał Grzelak
---
docs/grub.texi | 5 +
grub-core/commands/efi/tpm.c | 3 ++-
grub-core/commands/tpm.c | 7 ---
include/grub/tpm.h | 9 +
4 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index 9b58886a9..fc4e08f2c 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3841,6 +3841,11 @@ If this variable is set and true (i.e., not set to
``0'', ``false'',
fatal. Otherwise, they will merely be debug-logged and boot will
continue.
+Call to EFI firmware, like hash_log_extend_event(), can return an unknown
+error, i.e. due to bug present in firmware. When this variable is set and
+true (same values as with TPM measurements) this situation will be considered
+to be fatal and error-logged as ``unknown TPM error''. If not set, booting
+the OS will be enabled.
@node Environment block
@section The GRUB environment block
diff --git a/grub-core/commands/efi/tpm.c b/grub-core/commands/efi/tpm.c
index c616768f9..508ae8b3a 100644
--- a/grub-core/commands/efi/tpm.c
+++ b/grub-core/commands/efi/tpm.c
@@ -146,7 +146,8 @@ grub_efi_log_event_status (grub_efi_status_t status)
case GRUB_EFI_NOT_FOUND:
return grub_error (GRUB_ERR_UNKNOWN_DEVICE, N_("TPM unavailable"));
default:
- return grub_error (GRUB_ERR_UNKNOWN_DEVICE, N_("unknown TPM error"));
+ return grub_error (is_tpm_fail_fatal () ? GRUB_ERR_UNKNOWN_DEVICE
+ : GRUB_ERR_NONE, N_("unknown TPM error"));
}
}
diff --git a/grub-core/commands/tpm.c b/grub-core/commands/tpm.c
index 9f830916d..c7e599170 100644
--- a/grub-core/commands/tpm.c
+++ b/grub-core/commands/tpm.c
@@ -18,7 +18,6 @@
* Core TPM support code.
*/
-#include
#include
#include
#include
@@ -40,12 +39,6 @@ grub_tpm_verify_init (grub_file_t io,
return GRUB_ERR_NONE;
}
-static inline bool
-is_tpm_fail_fatal (void)
-{
- return grub_env_get_bool ("tpm_fail_fatal", false);
-}
-
static grub_err_t
grub_tpm_verify_write (void *context, void *buf, grub_size_t size)
{
diff --git a/include/grub/tpm.h b/include/grub/tpm.h
index c19fcbd0a..11238da18 100644
--- a/include/grub/tpm.h
+++ b/include/grub/tpm.h
@@ -19,6 +19,8 @@
#ifndef GRUB_TPM_HEADER
#define GRUB_TPM_HEADER 1
+#include
+
#define GRUB_STRING_PCR 8
#define GRUB_BINARY_PCR 9
@@ -37,4 +39,11 @@
grub_err_t grub_tpm_measure (unsigned char *buf, grub_size_t size,
grub_uint8_t pcr, const char *description);
int grub_tpm_present (void);
+
+static inline bool
+is_tpm_fail_fatal (void)
+{
+ return grub_env_get_bool ("tpm_fail_fatal", false);
+}
+
#endif
--
2.37.3
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
GRUB 2.02 and APFS filesystems causing boot-time issue
Hi all, I'm new to this list and I hope it's the right place to ask for help.. I'd like to better understand how to rebuild grubx64.efi from upstream source so I could give a try at fixing the issue I've come across: https://bugzilla.redhat.com/show_bug.cgi?id=1524685 https://savannah.gnu.org/bugs/?64304 Long story short: the simple presence of an APFS filesystem on any disk in an x86_64 system makes GRUB spit out errors (as if multiple disks were unreadable). The machine still boots fine (after pressing 'q') but the process requires human intervention on every reboot. The machine in question is a Mac Pro (Later 2013) but at this point I'm pretty sure it's a software problem since changing the partition type of the APFS partition to something else makes GRUB happy again. This system uses UEFI and the Linux boot entry shows this: [root@neraka ~]# efibootmgr -v|grep shim Boot* Red Hat Enterprise Linux HD(2,GPT,d36bfc93-9920-4346-9c56-bd7c57bdb0bb,0x1000,0x3f800)/File(\EFI\redhat\shimx64.efi) Is my interpretation of the issue correct? Something causes GRUB to get confused when it probes/enumerates the partition and it fails in shimx64.efi (a signed grubx64.efi rebuild) Since shimx64.efi is a signed binary which would not possible for me to rebuild, am I correct to think that I instead want to boot grubx64.efi an learn how to rebuild it (with efibootmgr it would be easy to add another entry pointing to that binary and try to boot from it). I would love to have a few pointers, Thank you. (I've done some 'C' and 'ASM' in my past lives so I hope that will be enough... ) :) Thank you for your consideration, Vincent ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] efi: Add missing __grub_efi_api attributes
Daniel Kiper on Thu, 2023/06/15 16:45:
> The commit bb4aa6e06 (efi: Drop all uses of efi_call_XX() wrappers) did
> not add some __grub_efi_api attributes to the EFI calls. Lack of them
> led to hangs on x86_64-efi target. So, let's add missing __grub_efi_api
> attributes.
>
> Fixes: bb4aa6e06 (efi: Drop all uses of efi_call_XX() wrappers)
I can confirm this fixes the issue for me. Thanks a lot!
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}
pgpCviyNPEndj.pgp
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v4 3/5] efi: Drop all uses of efi_call_XX wrappers
Daniel Kiper on Thu, 2023/06/15 17:05:
> > It looks I was able to reproduce this problem. I will be checking what
> > is going on in following days...
>
> Here [1] is the fix. Please test...
Works for me, thanks!
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}
pgpG4nzvtPfGC.pgp
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v4 3/5] efi: Drop all uses of efi_call_XX wrappers
On Wed, Jun 14, 2023 at 05:15:43PM +0200, Daniel Kiper wrote: > On Mon, Jun 12, 2023 at 10:53:09PM +0200, Robin Candau wrote: > > Le 12/06/2023 à 21:05, Daniel Kiper a écrit : > > > On Mon, Jun 12, 2023 at 07:19:53PM +0200, Christian Hesse wrote: > > > > Ard Biesheuvel on Tue, 2023/05/23 17:31: > > > > > Now that GCC can generate function calls using the correct calling > > > > > convention for us, we can stop using the efi_call_XX () wrappers, and > > > > > just dereference the function pointers directly. > > > > > > > > > > This avoids the untyped variadic wrapper routines, which means better > > > > > type checking for the method calls. > > > > Building an Arch package from current git master makes the system > > > > unbootable > > > > with just a black screen. We did biscect this and found this commit > > > > (bb4aa6e06ee3877110a1dc0eb0d766ffac978993 in master) to be the first > > > > bad one. > > > > > > > > As gcc is mentioned in the commit message... We are building with gcc > > > > 13.1.1-1. Any idea what is going on here? > > > Could you provide us more details? On which architecture/target do > > > you run tests? Does GRUB start? If yes which kernel version do you > > > try to boot? Could you send us a link to the GRUB and kernel packages > > > and sources? Etc... > > > > > > Daniel > > > > Hi, > > > > Tests have been ran on a x86_64 laptop (but the issue has been reproduced on > > several other x86_64 machines). GRUB does not start, we don't even reach the > > GRUB menu, nothing more than a black screen at boot. > > The kernel we're trying to boot is `linux 6.3.7-arch1-1` [1] (package [2]), > > but I doubt the kernel itself is in cause as we're able to boot it with a > > GRUB package built without the bb4aa6e06ee3877110a1dc0eb0d766ffac978993 > > commit. Here's a working GRUB package [3] and a faulty one [4]. > > Sources are taken from https://git.savannah.gnu.org/git/grub.git [5]. > > > > I remain available if you need specific tests or additional information. > > > > [1] https://archlinux.org/packages/core/x86_64/linux/ > > [2] > > http://www.gtlib.gatech.edu/pub/archlinux/core/os/x86_64/linux-6.3.7.arch1-1-x86_64.pkg.tar.zst > > [3] > > https://pkgbuild.com/~eworm/grub/grub-2:2.06.r535.g6a080b9cd-2-x86_64.pkg.tar.zst > > [4] > > https://pkgbuild.com/~eworm/grub/grub-2:2.06.r554.gc016a969d-2-x86_64.pkg.tar.zst > > [5] > > https://gitlab.archlinux.org/archlinux/packaging/packages/grub/-/blob/main/PKGBUILD#L60 > > It looks I was able to reproduce this problem. I will be checking what > is going on in following days... Here [1] is the fix. Please test... Daniel [1] https://lists.gnu.org/archive/html/grub-devel/2023-06/msg00092.html ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v4 3/5] efi: Drop all uses of efi_call_XX wrappers
On Wed, Jun 14, 2023 at 5:17 PM Daniel Kiper wrote: > > On Mon, Jun 12, 2023 at 10:53:09PM +0200, Robin Candau wrote: > > Le 12/06/2023 à 21:05, Daniel Kiper a écrit : > > > On Mon, Jun 12, 2023 at 07:19:53PM +0200, Christian Hesse wrote: > > > > Ard Biesheuvel on Tue, 2023/05/23 17:31: > > > > > Now that GCC can generate function calls using the correct calling > > > > > convention for us, we can stop using the efi_call_XX () wrappers, and > > > > > just dereference the function pointers directly. > > > > > > > > > > This avoids the untyped variadic wrapper routines, which means better > > > > > type checking for the method calls. > > > > Building an Arch package from current git master makes the system > > > > unbootable > > > > with just a black screen. We did biscect this and found this commit > > > > (bb4aa6e06ee3877110a1dc0eb0d766ffac978993 in master) to be the first > > > > bad one. > > > > > > > > As gcc is mentioned in the commit message... We are building with gcc > > > > 13.1.1-1. Any idea what is going on here? > > > Could you provide us more details? On which architecture/target do > > > you run tests? Does GRUB start? If yes which kernel version do you > > > try to boot? Could you send us a link to the GRUB and kernel packages > > > and sources? Etc... > > > > > > Daniel > > > > Hi, > > > > Tests have been ran on a x86_64 laptop (but the issue has been reproduced on > > several other x86_64 machines). GRUB does not start, we don't even reach the > > GRUB menu, nothing more than a black screen at boot. > > The kernel we're trying to boot is `linux 6.3.7-arch1-1` [1] (package [2]), > > but I doubt the kernel itself is in cause as we're able to boot it with a > > GRUB package built without the bb4aa6e06ee3877110a1dc0eb0d766ffac978993 > > commit. Here's a working GRUB package [3] and a faulty one [4]. > > Sources are taken from https://git.savannah.gnu.org/git/grub.git [5]. > > > > I remain available if you need specific tests or additional information. > > > > [1] https://archlinux.org/packages/core/x86_64/linux/ > > [2] > > http://www.gtlib.gatech.edu/pub/archlinux/core/os/x86_64/linux-6.3.7.arch1-1-x86_64.pkg.tar.zst > > [3] > > https://pkgbuild.com/~eworm/grub/grub-2:2.06.r535.g6a080b9cd-2-x86_64.pkg.tar.zst > > [4] > > https://pkgbuild.com/~eworm/grub/grub-2:2.06.r554.gc016a969d-2-x86_64.pkg.tar.zst > > [5] > > https://gitlab.archlinux.org/archlinux/packaging/packages/grub/-/blob/main/PKGBUILD#L60 > > It looks I was able to reproduce this problem. I will be checking what > is going on in following days... > > Daniel After looking at the patch, I would assume that the __grub_efi_api calling convention annotiation is missing in the protocol definitions of include/grub/efi/console_control.h include/grub/efi/graphics_output.h include/grub/efi/uga_draw.h > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] bootstrap: Fix patching warnings
Currently bootstrap complains in the following way when
patching gnulib files:
patching file argp-help.c
Hunk #1 succeeded at 52 (offset 1 line).
Hunk #2 succeeded at 1548 (offset 115 lines).
patching file mbswidth.c
patching file mbswidth.h
Hunk #1 succeeded at 40 (offset -5 lines).
Let's fix it by amending line numbers in the patch.
Signed-off-by: Daniel Kiper
---
grub-core/lib/gnulib-patches/fix-width.patch | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/grub-core/lib/gnulib-patches/fix-width.patch
b/grub-core/lib/gnulib-patches/fix-width.patch
index 0a208ad08..15f091c0d 100644
--- a/grub-core/lib/gnulib-patches/fix-width.patch
+++ b/grub-core/lib/gnulib-patches/fix-width.patch
@@ -143,7 +143,7 @@ diff --git a/lib/argp-help.c b/lib/argp-help.c
index e5375a0f0..5d8f451ec 100644
--- a/lib/argp-help.c
+++ b/lib/argp-help.c
-@@ -51,6 +51,7 @@
+@@ -52,6 +52,7 @@
#include "argp.h"
#include "argp-fmtstream.h"
#include "argp-namefrob.h"
@@ -151,7 +151,7 @@ index e5375a0f0..5d8f451ec 100644
#ifndef SIZE_MAX
# define SIZE_MAX ((size_t) -1)
-@@ -1432,7 +1433,7 @@ argp_args_usage (const struct argp *argp, const struct
argp_state *state,
+@@ -1547,7 +1548,7 @@ argp_args_usage (const struct argp *argp, const struct
argp_state *state,
/* Manually do line wrapping so that it (probably) won't get wrapped at
any embedded spaces. */
@@ -204,7 +204,7 @@ diff --git a/lib/mbswidth.h b/lib/mbswidth.h
index 2b5c53c37..45a123e63 100644
--- a/lib/mbswidth.h
+++ b/lib/mbswidth.h
-@@ -45,6 +45,10 @@ extern "C" {
+@@ -40,6 +40,10 @@ extern "C" {
control characters and 1 otherwise. */
#define MBSW_REJECT_UNPRINTABLE 2
--
2.11.0
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] efi: Add missing __grub_efi_api attributes
The commit bb4aa6e06 (efi: Drop all uses of efi_call_XX() wrappers) did
not add some __grub_efi_api attributes to the EFI calls. Lack of them
led to hangs on x86_64-efi target. So, let's add missing __grub_efi_api
attributes.
Fixes: bb4aa6e06 (efi: Drop all uses of efi_call_XX() wrappers)
Reported-by: Christian Hesse
Reported-by: Robin Candau
Signed-off-by: Daniel Kiper
---
include/grub/efi/cc.h | 30 ++--
include/grub/efi/console_control.h | 16 +++
include/grub/efi/graphics_output.h | 32 +++---
include/grub/efi/uga_draw.h| 40 +++---
4 files changed, 59 insertions(+), 59 deletions(-)
diff --git a/include/grub/efi/cc.h b/include/grub/efi/cc.h
index 896030689..978e0cdfe 100644
--- a/include/grub/efi/cc.h
+++ b/include/grub/efi/cc.h
@@ -124,27 +124,27 @@ typedef struct grub_efi_cc_boot_service_capability
grub_efi_cc_boot_service_capa
struct grub_efi_cc_protocol
{
grub_efi_status_t
- (*get_capability) (struct grub_efi_cc_protocol *this,
-grub_efi_cc_boot_service_capability_t *ProtocolCapability);
+ (__grub_efi_api *get_capability) (struct grub_efi_cc_protocol *this,
+ grub_efi_cc_boot_service_capability_t
*ProtocolCapability);
grub_efi_status_t
- (*get_event_log) (struct grub_efi_cc_protocol *this,
- grub_efi_cc_event_log_format_t EventLogFormat,
- grub_efi_physical_address_t *EventLogLocation,
- grub_efi_physical_address_t *EventLogLastEntry,
- grub_efi_boolean_t *EventLogTruncated);
+ (__grub_efi_api *get_event_log) (struct grub_efi_cc_protocol *this,
+ grub_efi_cc_event_log_format_t
EventLogFormat,
+ grub_efi_physical_address_t
*EventLogLocation,
+ grub_efi_physical_address_t
*EventLogLastEntry,
+ grub_efi_boolean_t *EventLogTruncated);
grub_efi_status_t
- (*hash_log_extend_event) (struct grub_efi_cc_protocol *this,
- grub_efi_uint64_t Flags,
- grub_efi_physical_address_t DataToHash,
- grub_efi_uint64_t DataToHashLen,
- grub_efi_cc_event_t *EfiCcEvent);
+ (__grub_efi_api *hash_log_extend_event) (struct grub_efi_cc_protocol *this,
+ grub_efi_uint64_t Flags,
+ grub_efi_physical_address_t
DataToHash,
+ grub_efi_uint64_t DataToHashLen,
+ grub_efi_cc_event_t *EfiCcEvent);
grub_efi_status_t
- (*map_pcr_to_mr_index) (struct grub_efi_cc_protocol *this,
- grub_efi_uint32_t PcrIndex,
- grub_efi_cc_mr_index_t *MrIndex);
+ (__grub_efi_api *map_pcr_to_mr_index) (struct grub_efi_cc_protocol *this,
+grub_efi_uint32_t PcrIndex,
+grub_efi_cc_mr_index_t *MrIndex);
};
typedef struct grub_efi_cc_protocol grub_efi_cc_protocol_t;
diff --git a/include/grub/efi/console_control.h
b/include/grub/efi/console_control.h
index bb5fd038e..008ac5896 100644
--- a/include/grub/efi/console_control.h
+++ b/include/grub/efi/console_control.h
@@ -41,18 +41,18 @@ typedef enum grub_efi_screen_mode grub_efi_screen_mode_t;
struct grub_efi_console_control_protocol
{
grub_efi_status_t
- (*get_mode) (struct grub_efi_console_control_protocol *this,
- grub_efi_screen_mode_t *mode,
- grub_efi_boolean_t *uga_exists,
- grub_efi_boolean_t *std_in_locked);
+ (__grub_efi_api *get_mode) (struct grub_efi_console_control_protocol *this,
+ grub_efi_screen_mode_t *mode,
+ grub_efi_boolean_t *uga_exists,
+ grub_efi_boolean_t *std_in_locked);
grub_efi_status_t
- (*set_mode) (struct grub_efi_console_control_protocol *this,
- grub_efi_screen_mode_t mode);
+ (__grub_efi_api *set_mode) (struct grub_efi_console_control_protocol *this,
+ grub_efi_screen_mode_t mode);
grub_efi_status_t
- (*lock_std_in) (struct grub_efi_console_control_protocol *this,
- grub_efi_char16_t *password);
+ (__grub_efi_api *lock_std_in) (struct grub_efi_console_control_protocol
*this,
+grub_efi_char16_t *password);
};
typedef struct grub_efi_console_control_protocol
grub_efi_console_control_protocol_t;
diff --git a/include/grub/efi/graphics_output.h
b/include/grub/efi/graphics_output.h
index e4388127c..044e786b8 100644
--- a/include/grub/efi/graphics_output.h
+++ b/include/grub/efi/graphics_output.h
@@ -83,26 +83,26 @@ struct grub_efi_gop_mode
struct
[PATCH v5 0/1] loongarch: Disable relaxation for grub
v4->v5: - update commit message v3->v4: - rebase on the latest master branch - check "-mno-relax" and "-Wa,-mno-relax" v2->v3: - Use the -mno-relax cflags for gcc v1->v2: - split patch - drop cast code Xiaotian Wu (1): loongarch: disable relaxation relocations configure.ac | 23 +++ 1 file changed, 23 insertions(+) -- 2.40.1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v5 1/1] loongarch: disable relaxation relocations
A working grub cannot be built with upcoming binutils and gcc, because linker
relaxation was added [1] causing new unsupported relocations to appear in
modules.
So we pass -mno-relax to gcc if it is supported, to disable relaxation and make
grub forward-compatible with new toolchains.
While similar code already exists for sparc64 in configure.ac, sparc64 sets
LDFLAGS while loongarch requires CFLAGS to be set. If we only set LDFLAGS on
loongarch, gcc will still generate relaxation relocations in the .o files, so
the sparc64 code cannot be reused.
[1]:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=56576f4a722b7398d35802ecf7d4185c27d6d69b
Signed-off-by: Xiaotian Wu
---
configure.ac | 23 +++
1 file changed, 23 insertions(+)
diff --git a/configure.ac b/configure.ac
index d9f088d12..a0ea5beae 100644
--- a/configure.ac
+++ b/configure.ac
@@ -874,6 +874,29 @@ if test "x$target_cpu" = xloongarch64; then
TARGET_CFLAGS="$TARGET_CFLAGS -mno-explicit-relocs -fno-plt"
TARGET_CCASFLAGS="$TARGET_CCASFLAGS -mno-explicit-relocs -fno-plt"
fi
+
+ AC_CACHE_CHECK([for no-relax options], grub_cv_target_cc_mno_relax, [
+grub_cv_target_cc_mno_relax=no
+for cand in "-mno-relax" "-Wa,-mno-relax"; do
+ if test x"$grub_cv_target_cc_mno_relax" != xno ; then
+break
+ fi
+ CFLAGS="$TARGET_CFLAGS $cand -Werror"
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([[
+ asm (".globl start; start:");
+ void __main (void);
+ void __main (void) {}
+ int main (void);
+ ]], [[]])], [grub_cv_target_cc_mno_relax="$cand"], [])
+done
+ ])
+ CFLAGS="$TARGET_CFLAGS"
+
+ if test x"$grub_cv_target_cc_mno_relax" != xno ; then
+TARGET_CFLAGS="$TARGET_CFLAGS $grub_cv_target_cc_mno_relax"
+TARGET_CCASFLAGS="$TARGET_CCASFLAGS $grub_cv_target_cc_mno_relax"
+ fi
+
TARGET_CFLAGS="$TARGET_CFLAGS -Wa,-mla-global-with-abs"
TARGET_CCASFLAGS="$TARGET_CCASFLAGS -Wa,-mla-global-with-abs"
fi
--
2.40.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] tpm: Enable boot despite unknown firmware failure
On Wed, Jun 14, 2023 at 04:59:29PM +0200, Michał Grzelak wrote:
> Currently booting the system is prevented when call to EFI firmware
> hash_log_extend_event() returns unknown error. Solve this by following
> convention used in commit a4356538d (commands/tpm: Don't propagate
> measurement failures to the verifiers layer).
>
> Let the system to be bootable by default when unknown TPM error is
> encountered. Make grub_tpm_is_fail_fatal() global and move its body to
> efi/tpm.c. Check environment variable tpm_fail_fatal to fallback to
> previous behaviour.
>
> Signed-off-by: Michał Grzelak
> ---
> grub-core/commands/efi/tpm.c | 10 +-
> grub-core/commands/tpm.c | 11 ++-
> include/grub/tpm.h | 1 +
> 3 files changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/grub-core/commands/efi/tpm.c b/grub-core/commands/efi/tpm.c
> index c616768f9..05f3064f7 100644
> --- a/grub-core/commands/efi/tpm.c
> +++ b/grub-core/commands/efi/tpm.c
> @@ -18,6 +18,7 @@
> * EFI TPM support code.
> */
>
> +#include
> #include
> #include
> #include
> @@ -146,7 +147,8 @@ grub_efi_log_event_status (grub_efi_status_t status)
> case GRUB_EFI_NOT_FOUND:
>return grub_error (GRUB_ERR_UNKNOWN_DEVICE, N_("TPM unavailable"));
> default:
> - return grub_error (GRUB_ERR_UNKNOWN_DEVICE, N_("unknown TPM error"));
> + return grub_error (grub_tpm_is_fail_fatal () ? GRUB_ERR_UNKNOWN_DEVICE
> + : GRUB_ERR_NONE, N_("unknown TPM error"));
> }
> }
>
> @@ -266,6 +268,12 @@ grub_cc_log_event (unsigned char *buf, grub_size_t size,
> grub_uint8_t pcr,
> grub_efi_log_event_status (status);
> }
>
> +bool
> +grub_tpm_is_fail_fatal (void)
> +{
> + return grub_env_get_bool ("tpm_fail_fatal", false);
> +}
> +
This function should be defined in the include/grub/tpm.h as
static inline bool
is_tpm_fail_fatal (void)
{
return grub_env_get_bool ("tpm_fail_fatal", false);
}
Of course you should include grub/env.h there too. And probably docs excerpt
introduced by commit a4356538d should be generalized a bit too...
Otherwise patch LGTM...
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Generalize MD_MAX_DISKS to GRUB_MDRAID_MAX_DISKS
On Tue, Jun 13, 2023 at 12:33:36PM -0700, Kees Cook wrote: > On Tue, Jun 13, 2023 at 02:54:48PM +0200, Julian Andres Klode wrote: > > Move the constant from getroot.c to disk.h and then reuse > > it place of the hardcoded 1024 limit in diskfilter. > > > > Fixes: 2a5e3c1f2 (disk/diskfilter: Don't make a RAID array with more than > > 1024 disks) > > Cc: Daniel Axtens > > Cc: Kees Cook > > Yup, looks good to me. Thanks! > > Reviewed-by: Kees Cook Reviewed-by: Daniel Kiper Thank you for fixing this issue. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 5/5] loongarch: Use the -mno-relax cflags for gcc
On Thu, Jun 15, 2023 at 10:04:23AM +0800, Xiaotian Wu wrote: > 在 2023-06-13星期二的 20:09 +0800，Xi Ruoyao via Grub-devel写道： > > On Tue, 2023-06-13 at 13:39 +0200, Daniel Kiper wrote: > > > On Tue, Jun 13, 2023 at 05:06:35PM +0800, Xiaotian Wu wrote: > > > > Because the binutils of the loongarch architecture adds > > > > relaxation > > > > support [1], > > > > the next version of binutils will not be able to build grub. > > > > > > > > So we use the -mno-relax cflags to disable gcc to generate > > > > relaxation > > > > relocations to enhance the compatibility of grub. > > > > > > > > [1]: > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=56576f4a722b7398d35802ecf7d4185c27d6d69b > > > > > > > > Signed-off-by: Xiaotian Wu > > > > --- > > > > configure.ac | 12 > > > > 1 file changed, 12 insertions(+) > > > > > > > > diff --git a/configure.ac b/configure.ac > > > > index d9f088d12..cd3cc6ba8 100644 > > > > --- a/configure.ac > > > > +++ b/configure.ac > > > > @@ -874,6 +874,18 @@ if test "x$target_cpu" = xloongarch64; then > > > > TARGET_CFLAGS="$TARGET_CFLAGS -mno-explicit-relocs -fno-plt" > > > > TARGET_CCASFLAGS="$TARGET_CCASFLAGS -mno-explicit-relocs - > > > > fno- > > > > plt" > > > > fi > > > > + > > > > + AC_CACHE_CHECK([whether _mno_relax works], > > > > [grub_cv_cc_mno_relax], [ > > > > + CFLAGS="$TARGET_CFLAGS -mno-relax -Werror" > > > > + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])], > > > > + [grub_cv_cc_mno_relax=yes], > > > > + [grub_cv_cc_mno_relax=no]) > > > > + ]) > > > > + if test "x$grub_cv_cc_mno_relax" = xyes; then > > > > + TARGET_CFLAGS="$TARGET_CFLAGS -mno-relax" > > > > + TARGET_CCASFLAGS="$TARGET_CCASFLAGS -mno-relax" > > > > + fi > > > > > > Could not you reuse sparc64 code which is ~100 lines below? If not > > > please make loongarch code as similar as possible to the sparc64 > > > one. > > > > More important reason is we need to try -Wa,-mno-relax along with - > > mno- > > relax, like SPARC64. GCC 13 and earlier does not accept -mno-relax, > > but > > the assembler itself can still generate R_LARCH_RELAX etc. So if a > > distro uses GCC 13 alongside Binutils 2.41, we'll need -Wa,-mno- > > relax. > > > > Note that Binutils 2.41 will be released in Feb 2024 but GCC 14 will > > be > > released in mid 2024 (Apr to Jun) so it can be expected that some > > distros will really use Binutils 2.41 and GCC 13. > > Code for sparc64 cannot be reused. > Because sparc64 sets LDFLAGS, and loongarch needs to set CFLAGS. > If only LDFLAGS is used on loongarch, gcc still generates .o files with > RELAX. The v4 LGTM but please add this explanation or something like that to the commit message and send v5. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3] docs: Add debugging chapter to development documentation
On Thu, Jun 15, 2023 at 01:21:57AM -0500, Oskari Pirhonen wrote: > Oops, apologies for the late reply. Reading through it again, I found a > few more small nits: Right now patch is in the git repo. If you want to improve that part of doc please send a fix to grub-devel and CC interested folks. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3] docs: Add debugging chapter to development documentation
Oops, apologies for the late reply. Reading through it again, I found a
few more small nits:
On Tue, Jun 06, 2023 at 00:48:39 -0500, Glenn Washburn wrote:
> Debugging GRUB can be tricky and require arcane knowledge. This will
> help those unfamiliar with the process to get started debugging GRUB
> with less effort.
>
> Signed-off-by: Glenn Washburn
> ---
> Changes from v1:
> * Add gdbinfo section
> ---
> Interdiff against v2:
> diff --git a/docs/grub-dev.texi b/docs/grub-dev.texi
> index 188ca9c7ca6e..72470b42c61a 100644
> --- a/docs/grub-dev.texi
> +++ b/docs/grub-dev.texi
> @@ -638,7 +638,7 @@ various targets using @command{gdb} and the
> @samp{gdb_grub} GDB script.
>@section i386-pc
>
>The i386-pc target is a good place to start when first debugging GRUB2
> -because in some respects its easier than EFI platforms. The reason being
> +because in some respects it's easier than EFI platforms. The reason being
>that the initial load address is always known in advance. To start
>debugging GRUB2 first QEMU must be started in GDB stub mode. The following
>command is a simple illustration:
> @@ -688,11 +688,11 @@ it does add the module symbols with the appropriate
> offset.
>@section x86_64-efi
>
>Using GDB to debug GRUB2 for the x86_64-efi target has some similarities
> with
> -the i386-pc target. Please read be familiar with the @ref{i386-pc} section
> -when reading this one. Extra care must be used to run QEMU such that it
> boots
> -a UEFI firmware. This usually involves either using the @samp{-bios} option
> -with a UEFI firmware blob (eg. @file{OVMF.fd}) or loading the firmware via
> -pflash. This document will not go further into how to do this as there are
> +the i386-pc target. Please read and familiarize yourself with the
> @ref{i386-pc}
> +section when reading this one. Extra care must be used to run QEMU such
> that it
> +boots a UEFI firmware. This usually involves either using the @samp{-bios}
> +option with a UEFI firmware blob (eg. @file{OVMF.fd}) or loading the
> firmware
> +via pflash. This document will not go further into how to do this as there
> are
>ample resource on the web.
>
>Like all EFI implementations, on x86_64-efi the (U)EFI firmware that loads
> @@ -700,7 +700,7 @@ the GRUB2 EFI application determines at runtime where
> the application will
>be loaded. This means that we do not know where to tell GDB to load the
>symbols for the GRUB2 core until the (U)EFI firmware determines it. There
> are
>two good ways of figuring this out when running in QEMU: use a @ref{OVMF
> debug log,
> -debug build of OVMF} and check the debug log or have GRUB2 say where it is
> +debug build of OVMF} and check the debug log, or have GRUB2 say where it is
>loaded. Neither of these are ideal because they both generally give the
>information after GRUB2 is already running, which makes debugging early
> boot
>infeasible. Technically, the first method does give the load address before
> @@ -734,11 +734,11 @@ application must be run via QEMU at least once prior
> in order to get the
>load address. Two methods for obtaining the load address are described in
>two subsections below. Generally speaking, the load address does not change
>between QEMU runs. There are exceptions to this, namely that different
> -GRUB2 EFI applications can be run at different addresses. Also, its been
> +GRUB2 EFI applications can be run at different addresses. Also, it has been
>observed that after running the EFI application for the first time, the
>second run will some times have a different load address, but subsequent
>runs of the same EFI application will have the same load address as the
> -second run. And its a near certainty that if the GRUB EFI binary has
> changed,
> +second run. And it's a near certainty that if the GRUB EFI binary has
> changed,
>eg. been recompiled, the load address will also be different.
>
>This ability to predict what the load address will be allows one to assume
> @@ -752,7 +752,7 @@ gdb -x gdb_grub -ex 'dynamic_load_symbols @var{address
> of .text section}'
>@end example
>
>If you load the symbols in this manner and, after continuing execution, do
> -not see output showing the loading of modules symbol, then its very likely
> +not see output showing the loading of modules symbol, then it is very
> likely
>that the load address was incorrect.
>
>Another thing to be aware of is how the loading of the GRUB image by the
> @@ -760,8 +760,8 @@ firmware affects previously set software breakpoints.
> On x86 platforms,
>software breakpoints are implemented by GDB by writing a special processor
>instruction at the location of the desired breakpoint. This special
> instruction
>when executed will stop the program execution and hand control to the
> -debugger, GDB. GDB will first saves
