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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.