* [PATCH] kbuild: modversions: Fix relative CRC byte order interpretion
@ 2019-03-23 18:46 Fredrik Noring
2019-03-24 6:30 ` Fredrik Noring
0 siblings, 1 reply; 5+ messages in thread
From: Fredrik Noring @ 2019-03-23 18:46 UTC (permalink / raw)
To: Masahiro Yamada, Michal Marek, linux-kbuild
Cc: Ard Biesheuvel, Maciej W. Rozycki
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.
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.
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);
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] kbuild: modversions: Fix relative CRC byte order interpretion
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
0 siblings, 1 reply; 5+ messages in thread
From: Fredrik Noring @ 2019-03-24 6:30 UTC (permalink / raw)
To: Masahiro Yamada, Michal Marek, linux-kbuild
Cc: Ard Biesheuvel, Maciej W. Rozycki
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);
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] kbuild: modversions: Fix relative CRC byte order interpretion
2019-03-24 6:30 ` Fredrik Noring
@ 2019-03-25 4:03 ` Masahiro Yamada
2019-03-27 18:12 ` [PATCH v2] kbuild: modversions: Fix relative CRC byte order interpretation Fredrik Noring
0 siblings, 1 reply; 5+ messages in thread
From: Masahiro Yamada @ 2019-03-25 4:03 UTC (permalink / raw)
To: Fredrik Noring
Cc: Michal Marek, Linux Kbuild mailing list, Ard Biesheuvel,
Maciej W. Rozycki
Hi Fredrik,
On Sun, Mar 24, 2019 at 3:37 PM Fredrik Noring <noring@nocrew.org> wrote:
>
> 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?
Either will do.
If you send v2, could you please check the possible
typo in the subject?
interpretion -> interpretation ?
Masahiro
> 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);
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH v2] kbuild: modversions: Fix relative CRC byte order interpretation
2019-03-25 4:03 ` Masahiro Yamada
@ 2019-03-27 18:12 ` Fredrik Noring
2019-03-28 9:06 ` Masahiro Yamada
0 siblings, 1 reply; 5+ messages in thread
From: Fredrik Noring @ 2019-03-27 18:12 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Michal Marek, Linux Kbuild mailing list, Ard Biesheuvel,
Maciej W. Rozycki
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);
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v2] kbuild: modversions: Fix relative CRC byte order interpretation
2019-03-27 18:12 ` [PATCH v2] kbuild: modversions: Fix relative CRC byte order interpretation Fredrik Noring
@ 2019-03-28 9:06 ` Masahiro Yamada
0 siblings, 0 replies; 5+ messages in thread
From: Masahiro Yamada @ 2019-03-28 9:06 UTC (permalink / raw)
To: Fredrik Noring
Cc: Michal Marek, Linux Kbuild mailing list, Ard Biesheuvel,
Maciej W. Rozycki
On Thu, Mar 28, 2019 at 3:13 AM Fredrik Noring <noring@nocrew.org> wrote:
>
> 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
Applied to linux-kbuild/fixes. Thanks.
> ---
> 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);
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-03-28 9:06 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 ` [PATCH v2] kbuild: modversions: Fix relative CRC byte order interpretation Fredrik Noring
2019-03-28 9:06 ` Masahiro Yamada
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.