public inbox for linux-kbuild@vger.kernel.org
 help / color / mirror / Atom feed
From: Fredrik Noring <noring@nocrew.org>
To: Masahiro Yamada <yamada.masahiro@socionext.com>,
	Michal Marek <michal.lkml@markovi.net>,
	linux-kbuild@vger.kernel.org
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	"Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: [PATCH] kbuild: modversions: Fix relative CRC byte order interpretion
Date: Sun, 24 Mar 2019 07:30:19 +0100	[thread overview]
Message-ID: <20190324063019.GA2555@sx9> (raw)
In-Reply-To: <20190323184618.GA4916@sx9>

Masahiro, Michal --

> 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.
> 
> For example, when loading BE modules 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.

I realise that the description above is perhaps a bit too brief; although
the error is triggered by loading modules, the precise location of the
error is 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 BE modules compiled with a LE system load properly into
> a BE kernel.

One could note that it has also been tested 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.

Would you like me to send an updated description?

Fredrik

> Signed-off-by: Fredrik Noring <noring@nocrew.org>
> Fixes: 56067812d5b0 ("kbuild: modversions: add infrastructure for emitting relative CRCs")
> Cc: stable@vger.kernel.org
> ---
> 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);

  reply	other threads:[~2019-03-24  6:37 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 [this message]
2019-03-25  4:03   ` Masahiro Yamada
2019-03-27 18:12     ` [PATCH v2] kbuild: modversions: Fix relative CRC byte order interpretation Fredrik Noring
2019-03-28  9:06       ` 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=20190324063019.GA2555@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