All of lore.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 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.