All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Helge Deller <deller@gmx.de>, Lucas De Marchi <lucas.demarchi@intel.com>
Cc: jeyu@kernel.org, linux-modules@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org
Subject: Re: [PATCH v2] modules: Ensure natural alignment for .altinstructions and __bug_table sections
Date: Fri, 1 Jul 2022 14:23:39 -0700	[thread overview]
Message-ID: <Yr9l24rvCAPJvuJQ@bombadil.infradead.org> (raw)
In-Reply-To: <Yr8/gr8e8I7tVX4d@p100>

On Fri, Jul 01, 2022 at 08:40:02PM +0200, Helge Deller wrote:
> In the kernel image vmlinux.lds.S linker scripts the .altinstructions
> and __bug_table sections are 32- or 64-bit aligned because they hold 32-
> and/or 64-bit values.
> 
> But for modules the module.lds.S linker script doesn't define a default
> alignment yet, so the linker chooses the default byte alignment, which
> then leads to unnecessary unaligned memory accesses at runtime.
> 
> Usually such unaligned accesses are unnoticed, because either the
> hardware (as on x86 CPUs) or in-kernel exception handlers (e.g. on hppa
> or sparc) emulate and fix them up at runtime.
> 
> On hppa the 32-bit unalignment exception handler was temporarily broken
> due another bad commit, and as such wrong values were returned on
> unaligned accesses to the altinstructions table.

OK so some bad commit broke something which caused bad alignment access
on altinstructions... But why on modules?!

I am not aware of modules using alternatives, given that alternatives
are hacks to help with bootup. For modules we can use other things
like jump labels, static keys.

So I don't understand still how this happened yet.

> This then led to
> undefined behaviour because wrong kernel addresses were patched and we
> suddenly faced lots of unrelated bugs, as can be seen in this mail
> thread:
> https://lore.kernel.org/all/07d91863-dacc-a503-aa2b-05c3b92a1e39@bell.net/T/#mab602dfa32be5e229d5e192ab012af196d04d75d
> 
> This patch adds the missing natural alignment for kernel modules to
> avoid unnecessary (hard- or software-based) fixups.

Is it correct to infer that issue you found through a bad commit was
then through code inspection after the bad commit made the kernel do
something stupid with unaligned access to some module altinstructions
section ? Ie, that should not have happened.

I'd like to determine if this is a stable fix, a regression, etc. And
this is not yet clear.

  Luis

> 
> Signed-off-by: Helge Deller <deller@gmx.de>
> ---
>  scripts/module.lds.S | 2 ++
>  1 file changed, 2 insertions(+)
> 
> --
> v2: updated commit message
> 
> diff --git a/scripts/module.lds.S b/scripts/module.lds.S
> index 1d0e1e4dc3d2..3a3aa2354ed8 100644
> --- a/scripts/module.lds.S
> +++ b/scripts/module.lds.S
> @@ -27,6 +27,8 @@ SECTIONS {
>  	.ctors			0 : ALIGN(8) { *(SORT(.ctors.*)) *(.ctors) }
>  	.init_array		0 : ALIGN(8) { *(SORT(.init_array.*)) *(.init_array) }
> 
> +	.altinstructions	0 : ALIGN(8) { KEEP(*(.altinstructions)) }
> +	__bug_table		0 : ALIGN(8) { KEEP(*(__bug_table)) }
>  	__jump_table		0 : ALIGN(8) { KEEP(*(__jump_table)) }
> 
>  	__patchable_function_entries : { *(__patchable_function_entries) }

  reply	other threads:[~2022-07-01 21:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-01 18:40 [PATCH v2] modules: Ensure natural alignment for .altinstructions and __bug_table sections Helge Deller
2022-07-01 21:23 ` Luis Chamberlain [this message]
2022-07-02 16:24   ` Helge Deller
2022-07-07  0:48     ` Luis Chamberlain

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=Yr9l24rvCAPJvuJQ@bombadil.infradead.org \
    --to=mcgrof@kernel.org \
    --cc=deller@gmx.de \
    --cc=jeyu@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=lucas.demarchi@intel.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.