From: tip-bot for Josh Boyer <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, hpa@zytor.com, mingo@kernel.org,
holt@sgi.com, tglx@linutronix.de, jwboyer@gmail.com
Subject: [tip:x86/urgent] x86: Don' t clear efi_info even if the sentinel hits
Date: Wed, 6 Mar 2013 20:53:07 -0800 [thread overview]
Message-ID: <tip-2e604c0f19dcdd433b3863ffc3da9bc0787ca765@git.kernel.org> (raw)
In-Reply-To: <CA+5PVA51-FT14p4CRYKbicykugVb=PiaEycdQ57CK2km_OQuRQ@mail.gmail.com>
Commit-ID: 2e604c0f19dcdd433b3863ffc3da9bc0787ca765
Gitweb: http://git.kernel.org/tip/2e604c0f19dcdd433b3863ffc3da9bc0787ca765
Author: Josh Boyer <jwboyer@gmail.com>
AuthorDate: Wed, 6 Mar 2013 20:23:30 -0800
Committer: H. Peter Anvin <hpa@zytor.com>
CommitDate: Wed, 6 Mar 2013 20:23:30 -0800
x86: Don't clear efi_info even if the sentinel hits
When boot_params->sentinel is set, all we really know is that some
undefined set of fields in struct boot_params contain garbage. In the
particular case of efi_info, however, there is a private magic for
that substructure, so it is generally safe to leave it even if the
bootloader is broken.
kexec (for which we did the initial analysis) did not initialize this
field, but of course all the EFI bootloaders do, and most EFI
bootloaders are broken in this respect (and should be fixed.)
Reported-by: Robin Holt <holt@sgi.com>
Link: http://lkml.kernel.org/r/CA%2B5PVA51-FT14p4CRYKbicykugVb=PiaEycdQ57CK2km_OQuRQ@mail.gmail.com
Tested-by: Josh Boyer <jwboyer@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
---
arch/x86/include/asm/bootparam_utils.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/bootparam_utils.h b/arch/x86/include/asm/bootparam_utils.h
index 5b5e9cb..ff808ef 100644
--- a/arch/x86/include/asm/bootparam_utils.h
+++ b/arch/x86/include/asm/bootparam_utils.h
@@ -14,13 +14,15 @@
* analysis of kexec-tools; if other broken bootloaders initialize a
* different set of fields we will need to figure out how to disambiguate.
*
+ * Note: efi_info is commonly left uninitialized, but that field has a
+ * private magic, so it is better to leave it unchanged.
*/
static void sanitize_boot_params(struct boot_params *boot_params)
{
if (boot_params->sentinel) {
/*fields in boot_params are not valid, clear them */
memset(&boot_params->olpc_ofw_header, 0,
- (char *)&boot_params->alt_mem_k -
+ (char *)&boot_params->efi_info -
(char *)&boot_params->olpc_ofw_header);
memset(&boot_params->kbd_status, 0,
(char *)&boot_params->hdr -
next prev parent reply other threads:[~2013-03-07 4:54 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-28 20:52 Revert commit 5dcd14ecd4 - breaks EFI boot with SLES11 elilo.efi Robin Holt
2013-02-28 21:05 ` H. Peter Anvin
2013-02-28 21:09 ` Robin Holt
2013-02-28 21:12 ` H. Peter Anvin
2013-02-28 23:02 ` Yinghai Lu
2013-02-28 23:09 ` H. Peter Anvin
2013-03-05 8:15 ` Robin Holt
2013-03-05 15:22 ` H. Peter Anvin
2013-03-05 19:12 ` Yinghai Lu
2013-03-05 19:52 ` Robin Holt
2013-03-05 20:14 ` Yinghai Lu
2013-03-05 20:22 ` Robin Holt
2013-03-06 16:53 ` Josh Boyer
2013-03-06 17:26 ` H. Peter Anvin
2013-03-06 17:36 ` Josh Boyer
2013-03-06 17:37 ` H. Peter Anvin
2013-03-06 20:40 ` Josh Boyer
2013-03-06 20:43 ` H. Peter Anvin
2013-03-07 4:53 ` tip-bot for Josh Boyer [this message]
2013-03-06 18:00 ` [PATCH] Be explicit about what the x86 0x020c boot parameter version requires Peter Jones
2013-03-07 4:31 ` H. Peter Anvin
2013-03-07 8:39 ` Matt Fleming
2013-03-07 4:54 ` [tip:x86/urgent] x86, doc: Be explicit about what the x86 struct boot_params requires tip-bot for Peter Jones
2013-03-06 16:55 ` Revert commit 5dcd14ecd4 - breaks EFI boot with SLES11 elilo.efi Peter Jones
2013-03-06 17:14 ` H. Peter Anvin
2013-03-06 17:32 ` Peter Jones
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=tip-2e604c0f19dcdd433b3863ffc3da9bc0787ca765@git.kernel.org \
--to=tipbot@zytor.com \
--cc=holt@sgi.com \
--cc=hpa@zytor.com \
--cc=jwboyer@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
/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