linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arvind Sankar <nivedita@alum.mit.edu>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>,
	linux-efi <linux-efi@vger.kernel.org>,
	Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH 1/1] efi/libstub: Fix mixed mode boot issue after macro refactor
Date: Mon, 4 May 2020 10:27:41 -0400	[thread overview]
Message-ID: <20200504142741.GA21142@rani.riverdale.lan> (raw)
In-Reply-To: <CAMj1kXEjvRkcZ7_J9zVbqFoZsRfbDA8c_xyHRM+je2njHeDEMQ@mail.gmail.com>

On Mon, May 04, 2020 at 04:15:59PM +0200, Ard Biesheuvel wrote:
> On Mon, 4 May 2020 at 16:02, Arvind Sankar <nivedita@alum.mit.edu> wrote:
> >
> > On Mon, May 04, 2020 at 10:05:23AM +0200, Ard Biesheuvel wrote:
> > > On Mon, 4 May 2020 at 02:38, Arvind Sankar <nivedita@alum.mit.edu> wrote:
> > > >
> > > > Commit
> > > >   22090f84bc3f ("efi/libstub: unify EFI call wrappers for non-x86")
> > > >
> > > > refactored the macros that are used to provide wrappers for mixed-mode
> > > > calls on x86, allowing us to boot a 64-bit kernel on 32-bit firmware.
> > > >
> > > > Unfortunately, this broke mixed mode boot due to the fact that
> > > > efi_is_native() is not a macro on x86.
> > > >
> > > > Fix this by conditioning the generic macro definitions on
> > > > CONFIG_EFI_MIXED, and removing the wrapper definitions on x86 if
> > > > CONFIG_EFI_MIXED is not enabled.
> > > >
> > > > Reported-by: Guenter Roeck <linux@roeck-us.net>
> > > > Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
> > >
> > > Thanks Arvind.
> > >
> > > Currently, CONFIG_EFI_MIXED is never referenced outside of arch/x86,
> > > and I prefer to keep it that way.
> >
> > All these macros go together though -- they should either all be defined
> > or none, so it makes sense to put them under a single #if.
> 
> True.
> 
> > If you think
> > it's possible that a future architecture might need the wrappers but not
> > be mixed, we could maybe add an ARCH_NEEDS_EFISTUB_WRAPPERS?
> >
> 
> Well, remember that x86 used wrappers for native invocations only two
> releases ago, but that was mainly because of the SysV vs MS ABI issue,
> so the issue could emerge again, but it is unlikely.
> 

Yep.

Would the below be more palatable?

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index cd0c3fbf6156..6b9ab0d8b2a7 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -225,13 +225,15 @@ efi_status_t efi_set_virtual_address_map(unsigned long memory_map_size,
 
 /* arch specific definitions used by the stub code */
 
-extern const bool efi_is64;
+#ifdef CONFIG_EFI_MIXED
+
+#define ARCH_HAS_EFISTUB_WRAPPERS
 
 static inline bool efi_is_64bit(void)
 {
-	if (IS_ENABLED(CONFIG_EFI_MIXED))
-		return efi_is64;
-	return IS_ENABLED(CONFIG_X86_64);
+	extern const bool efi_is64;
+
+	return efi_is64;
 }
 
 static inline bool efi_is_native(void)
@@ -356,6 +358,15 @@ static inline u32 efi64_convert_status(efi_status_t status)
 						   runtime),		\
 				    func, __VA_ARGS__))
 
+#else /* CONFIG_EFI_MIXED */
+
+static inline bool efi_is_64bit(void)
+{
+	return IS_ENABLED(CONFIG_X86_64);
+}
+
+#endif /* CONFIG_EFI_MIXED */
+
 extern bool efi_reboot_required(void);
 extern bool efi_is_table_address(unsigned long phys_addr);
 
diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index 874233cf8820..4f10a09563f3 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -33,20 +33,14 @@ extern bool efi_novamap;
 
 extern const efi_system_table_t *efi_system_table;
 
-#ifndef efi_bs_call
+#ifndef ARCH_HAS_EFISTUB_WRAPPERS
+
+#define efi_is_native()		(true)
 #define efi_bs_call(func, ...)	efi_system_table->boottime->func(__VA_ARGS__)
-#endif
-#ifndef efi_rt_call
 #define efi_rt_call(func, ...)	efi_system_table->runtime->func(__VA_ARGS__)
-#endif
-#ifndef efi_is_native
-#define efi_is_native()		(true)
-#endif
-#ifndef efi_table_attr
 #define efi_table_attr(inst, attr)	(inst->attr)
-#endif
-#ifndef efi_call_proto
 #define efi_call_proto(inst, func, ...) inst->func(inst, ##__VA_ARGS__)
+
 #endif
 
 #define efi_info(msg)		do {			\

  reply	other threads:[~2020-05-04 14:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-03 15:45 [PATCH] efi/libstub/x86: fix mixed mode boot issue after macro refactor Ard Biesheuvel
2020-05-04  0:38 ` [PATCH 0/1] efi/libstub: Fix mixed mode boot on efi/next Arvind Sankar
2020-05-04  0:38   ` [PATCH 1/1] efi/libstub: Fix mixed mode boot issue after macro refactor Arvind Sankar
2020-05-04  8:05     ` Ard Biesheuvel
2020-05-04 14:02       ` Arvind Sankar
2020-05-04 14:15         ` Ard Biesheuvel
2020-05-04 14:27           ` Arvind Sankar [this message]
2020-05-04 14:33             ` Ard Biesheuvel
2020-05-04 15:02               ` [PATCH v2] " Arvind Sankar
2020-05-05  7:58                 ` Ard Biesheuvel
2020-05-04  2:25   ` [PATCH 0/1] efi/libstub: Fix mixed mode boot on efi/next Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200504142741.GA21142@rani.riverdale.lan \
    --to=nivedita@alum.mit.edu \
    --cc=ardb@kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).