Re: [PATCH 6/7] modules: Add CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC

From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: Jessica Yu <jeyu@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"kgdb-bugreport@lists.sourceforge.net" 
	<kgdb-bugreport@lists.sourceforge.net>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	Jason Wessel <jason.wessel@windriver.com>,
	Daniel Thompson <daniel.thompson@linaro.org>,
	Douglas Anderson <dianders@chromium.org>
Subject: Re: [PATCH 6/7] modules: Add CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC
Date: Wed, 26 Jan 2022 06:38:30 +0000	[thread overview]
Message-ID: <b49235ef-1fc3-7b8f-7e23-79f461d83e18@csgroup.eu> (raw)
In-Reply-To: <YfBnNuXpR2l2AuCP@bombadil.infradead.org>

Le 25/01/2022 à 22:10, Luis Chamberlain a écrit :
> On Mon, Jan 24, 2022 at 09:22:34AM +0000, Christophe Leroy wrote:
>> This can also be useful on other powerpc/32 in order to maximize the
>> chance of code being close enough to kernel core to avoid branch
>> trampolines.
> 
> Curious about all this branch trampoline talk. Do you have data to show
> negative impact with things as-is?

See 
https://github.com/linuxppc/linux/commit/2ec13df167040cd153c25c4d96d0ffc573ac4c40

Or 
https://github.com/linuxppc/linux/commit/7d485f647c1f4a6976264c90447fb0dbf07b111d

> 
> Also, was powerpc/32 broken then without this? The commit log seems to
> suggest so, but I don't think that's the case. How was this issue noticed?

Your question is related to the trampoline topic or the exec/noexec 
flagging ?

Regarding trampoline, everything is working OK. That's just cherry on 
the cake, when putting data away you can have more code closer to the 
kernel. But that would not have been a reason in itself for this series.

Regarding the exec/noexec discussion, it's a real issue. powerpc/32 
doesn't honor page exec flag, so when you select STRICT_MODULES_RWX and 
flag module data as no-exec, it remains executable. That's because 
powerpc/32 MMU doesn't have a per page exec flag but only a per 
256Mbytes segment exec flag.

Typical PPC32 layount:
0xf0000000-0xffffffff : VMALLOC AREA ==> NO EXEC
0xc0000000-0xefffffff : Linear kernel memory mapping
0xb0000000-0xbfffffff : MODULES AREA ==> EXEC
0x00000000-0xafffffff : User space ==> EXEC

So STRICT_MODULES_RWX is broken on some powerpc/32

> 
> Are there other future CPU families being planned where this is all true for
> as well? Are they goin to be 32-bit as well?

Future I don't know.

Regarding the trampoline stuff, I see at least the following existing 
architectures with a similar constraint:

ARM:

https://elixir.bootlin.com/linux/v5.16/source/arch/arm/include/asm/memory.h#L55

ARM even has a config item to allow trampolines or not. I might add the 
same to powerpc to reduce number of pages used by modules.

https://elixir.bootlin.com/linux/v5.16/source/arch/arm/Kconfig#L1514

NDS32 has the constraint

https://elixir.bootlin.com/linux/v5.16/source/arch/nds32/include/asm/memory.h#L41

NIOS2 has the constraint, allthough they handled it in a different way:

https://elixir.bootlin.com/linux/v5.16/source/arch/nios2/kernel/module.c#L30

Even ARM64 benefits from modules closer to kernel:

https://elixir.bootlin.com/linux/v5.16/source/arch/arm64/Kconfig#L1848

Another future opportunity with the ability to allocate module parts 
separately is the possibility to then use huge vmalloc mappings.

Today huge vmalloc mappings cannot be used for modules, see recent 
discussion at 
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20211227145903.187152-4-wangkefeng.wang@huawei.com/

Christophe