From: Fredrik Noring <noring@nocrew.org>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
"Maciej W. Rozycki" <macro@linux-mips.org>
Subject: [PATCH v2] kbuild: modversions: Fix relative CRC byte order interpretation
Date: Wed, 27 Mar 2019 19:12:50 +0100 [thread overview]
Message-ID: <20190327181250.GA2563@sx9> (raw)
In-Reply-To: <CAK7LNARM++Agci9Sg0P4XJ6NrRHG2JDEyp341cV2+vNwNeShaQ@mail.gmail.com>
Fix commit 56067812d5b0 ("kbuild: modversions: add infrastructure for
emitting relative CRCs") where CRCs are interpreted in host byte order
rather than proper kernel byte order. The bug is conditional on
CONFIG_MODULE_REL_CRCS.
For example, when loading a BE module into a BE kernel compiled with a LE
system, the error "disagrees about version of symbol module_layout" is
produced. A message such as "Found checksum D7FA6856 vs module 5668FAD7"
will be given with debug enabled, which indicates an obvious endian
problem within __kcrctab within the kernel image.
The general solution is to use the macro TO_NATIVE, as is done in
similar cases throughout modpost.c. With this correction it has been
verified that a BE kernel compiled with a LE system accepts BE modules.
This change has also been verified with a LE kernel compiled with a LE
system, in which case TO_NATIVE returns its value unmodified since the
byte orders match. This is by far the common case.
Fixes: 56067812d5b0 ("kbuild: modversions: add infrastructure for emitting relative CRCs")
Signed-off-by: Fredrik Noring <noring@nocrew.org>
Cc: stable@vger.kernel.org
---
Thank you for your review, Masahiro,
Changes in v2:
- Fix subject spelling mistake.
- Note that the bug is conditional on CONFIG_MODULE_REL_CRCS.
- Clarify kernel image and __kcrctab compilation details.
- Mention verification of matching LE byte order common case.
Fredrik
---
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 0b0d1080b1c5..f277e116e0eb 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -639,7 +639,7 @@ static void handle_modversions(struct module *mod, struct elf_info *info,
info->sechdrs[sym->st_shndx].sh_offset -
(info->hdr->e_type != ET_REL ?
info->sechdrs[sym->st_shndx].sh_addr : 0);
- crc = *crcp;
+ crc = TO_NATIVE(*crcp);
}
sym_update_crc(symname + strlen("__crc_"), mod, crc,
export);
next prev parent reply other threads:[~2019-03-27 18:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-23 18:46 [PATCH] kbuild: modversions: Fix relative CRC byte order interpretion Fredrik Noring
2019-03-24 6:30 ` Fredrik Noring
2019-03-25 4:03 ` Masahiro Yamada
2019-03-27 18:12 ` Fredrik Noring [this message]
2019-03-28 9:06 ` [PATCH v2] kbuild: modversions: Fix relative CRC byte order interpretation Masahiro Yamada
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=20190327181250.GA2563@sx9 \
--to=noring@nocrew.org \
--cc=ard.biesheuvel@linaro.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=michal.lkml@markovi.net \
--cc=yamada.masahiro@socionext.com \
/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