Re: [linux-yocto] [PATCH] modules: always page-align module section allocations
On Fri, Aug 16, 2019 at 12:01 PM wrote:
>
>
> 在 2019年8月16日 23:29，Paul Gortmaker 写下:
> >
> > [[linux-yocto] [PATCH] modules: always page-align module section
> > allocations] On 16/08/2019 (Fri 15:36) zhe...@windriver.com wrote:
> >
> > It helps maintainers if the version is embedded in the subject, like:
> >
> > [PATCH v4.18] modules: always page-align module section
> >
> > > From: Jessica Yu
> > >
> > > Some arches (e.g., arm64, x86) have moved towards non-executable
> > > module_alloc() allocations for security hardening reasons. That means
> > > that the module loader will need to set the text section of a module to
> > > executable, regardless of whether or not CONFIG_STRICT_MODULE_RWX is set.
> > >
> > > When CONFIG_STRICT_MODULE_RWX=y, module section allocations are always
> > > page-aligned to handle memory rwx permissions. On some arches with
> > > CONFIG_STRICT_MODULE_RWX=n however, when setting the module text to
> > > executable, the BUG_ON() in frob_text() gets triggered since module
> > > section allocations are not page-aligned when CONFIG_STRICT_MODULE_RWX=n.
> > > Since the set_memory_* API works with pages, and since we need to call
> > > set_memory_x() regardless of whether CONFIG_STRICT_MODULE_RWX is set, we
> > > might as well page-align all module section allocations for ease of
> > > managing rwx permissions of module sections (text, rodata, etc).
> > >
> > > Fixes: 2eef1399a866 ("modules: fix BUG when load module with rodata=n")
> > > Reported-by: Martin Kaiser
> > > Reported-by: Bartosz Golaszewski
> > > Tested-by: David Lechner
> > > Tested-by: Martin Kaiser
> > > Tested-by: Bartosz Golaszewski
> > > Signed-off-by: Jessica Yu
> > >
> > > commit 38f054d549a869f22a02224cd276a27bf14b6171 upstream
> >
> > Normally we put this right at the top of the long log. Also this commit
> > ID appears bogus - it does not exist in mainline.
>
> Yes, it's from modules-next,
> https://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git/commit/?h=modules-next
I went ahead and cleaned up the commit log, since we never say "commit
upstream", if "upstream" is not linus' main git repo. I've
pointed at modules-next, and hopefully it is well behaved and won't be
rebased.
I didn't see it in -rc5, so hopefully it makes it upstream soon.
>
> I can't wait as It blocks something.
>
> >
> > Also it seems very odd that the block of Signed-off lines are stuck in
> > the middle of the long log.
> >
> > >
> > > When loading modules with CONFIG_ARCH_HAS_STRICT_MODULE_RWX enabled and
> > > CONFIG_STRICT_MODULE_RWX disabled, the memory allocated for modules would
> > > not be page-aligned and cause the following BUG during frob_text.
> > >
> > > [ cut here ]
> > > kernel BUG at kernel/module.c:1907!
> > > Internal error: Oops - BUG: 0 [#1] ARM
> > > Modules linked in:
> > > CPU: 0 PID: 89 Comm: systemd-modules Not tainted 5.3.0-rc2 #1
> > > Hardware name: ARM-Versatile (Device Tree Support)
> > > PC is at frob_text.constprop.0+0x2c/0x40
> > > LR is at load_module+0x14b4/0x1d28
> > > pc : []lr : []psr: 2013
> > > sp : ce44fe58 ip : fp :
> > > r10: r9 : ce44feb8 r8 :
> > > r7 : 0001 r6 : bf00032c r5 : ce44ff40 r4 : bf000320
> > > r3 : bf000400 r2 : 0fff r1 : 0220 r0 : bf00
> > > Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> > > Control: 00093177 Table: 0e4c DAC: 0051
> > > Process systemd-modules (pid: 89, stack limit = 0x9fccc8dc)
> > > Stack: (0xce44fe58 to 0xce45)
> > > fe40:
> > > cf1b05b8
> > > fe60: 0001 ce47cf08 bf002754 c07ae5d8 d0a2a484 bf002060 bf0004f8
> > >
> > > fe80: b6d17910 c017cf1c ce47cf00 d0a29000 ce47cf00 ce44ff34 14fc
> > >
> > > fea0: bf00025c 0001 6e72656b
> > > 6c65
> > > fec0:
> > >
> > > fee0: c0ac9048 7fff
> > >
> > > ff00: b6d17910 0005 017b c0009208 ce44e000 b6ebfe54
> > > c008562c
> > > ff20: 7fff 0003 cefd28f8 0001 d0a29000 14fc
> > >
> > > ff40: d0a292cb d0a29380 d0a29000 14fc d0a29f0c d0a29d90 d0a29a60
> > > 0520
> > > ff60: 0710 0718 0826 0708
> > > 0023
> > > ff80: 0024 001c 0016 c0ac9048 0041c620
> > >
> > > ffa0: c0009000 0041c620 0005 b6d17910
> > >
> > > ffc0: 0041c620 017b 0041f078 004098b0
> > > b6ebfe54
> > > ffe0: bedb6bc8 bedb6bb8 b6d0f91c b6c945a0 6010 0005
> > >
> > > [] (frob_text.constprop.0) from []
> > > (load_module+0x14b4/0x1d28)
> > > [] (load_module) from [] (sys_finit_module+0xa0/0xc4)
> > > [] (sys_f
Re: [linux-yocto] [PATCH] modules: always page-align module section allocations
在 2019年8月16日 23:29，Paul Gortmaker 写下:
>
> [[linux-yocto] [PATCH] modules: always page-align module section allocations]
> On 16/08/2019 (Fri 15:36) zhe...@windriver.com wrote:
>
> It helps maintainers if the version is embedded in the subject, like:
>
> [PATCH v4.18] modules: always page-align module section
>
> > From: Jessica Yu
> >
> > Some arches (e.g., arm64, x86) have moved towards non-executable
> > module_alloc() allocations for security hardening reasons. That means
> > that the module loader will need to set the text section of a module to
> > executable, regardless of whether or not CONFIG_STRICT_MODULE_RWX is set.
> >
> > When CONFIG_STRICT_MODULE_RWX=y, module section allocations are always
> > page-aligned to handle memory rwx permissions. On some arches with
> > CONFIG_STRICT_MODULE_RWX=n however, when setting the module text to
> > executable, the BUG_ON() in frob_text() gets triggered since module
> > section allocations are not page-aligned when CONFIG_STRICT_MODULE_RWX=n.
> > Since the set_memory_* API works with pages, and since we need to call
> > set_memory_x() regardless of whether CONFIG_STRICT_MODULE_RWX is set, we
> > might as well page-align all module section allocations for ease of
> > managing rwx permissions of module sections (text, rodata, etc).
> >
> > Fixes: 2eef1399a866 ("modules: fix BUG when load module with rodata=n")
> > Reported-by: Martin Kaiser
> > Reported-by: Bartosz Golaszewski
> > Tested-by: David Lechner
> > Tested-by: Martin Kaiser
> > Tested-by: Bartosz Golaszewski
> > Signed-off-by: Jessica Yu
> >
> > commit 38f054d549a869f22a02224cd276a27bf14b6171 upstream
>
> Normally we put this right at the top of the long log. Also this commit
> ID appears bogus - it does not exist in mainline.
Yes, it's from modules-next,
https://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git/commit/?h=modules-next
I can't wait as It blocks something.
>
> Also it seems very odd that the block of Signed-off lines are stuck in
> the middle of the long log.
>
> >
> > When loading modules with CONFIG_ARCH_HAS_STRICT_MODULE_RWX enabled and
> > CONFIG_STRICT_MODULE_RWX disabled, the memory allocated for modules would
> > not be page-aligned and cause the following BUG during frob_text.
> >
> > [ cut here ]
> > kernel BUG at kernel/module.c:1907!
> > Internal error: Oops - BUG: 0 [#1] ARM
> > Modules linked in:
> > CPU: 0 PID: 89 Comm: systemd-modules Not tainted 5.3.0-rc2 #1
> > Hardware name: ARM-Versatile (Device Tree Support)
> > PC is at frob_text.constprop.0+0x2c/0x40
> > LR is at load_module+0x14b4/0x1d28
> > pc : []lr : []psr: 2013
> > sp : ce44fe58 ip : fp :
> > r10: r9 : ce44feb8 r8 :
> > r7 : 0001 r6 : bf00032c r5 : ce44ff40 r4 : bf000320
> > r3 : bf000400 r2 : 0fff r1 : 0220 r0 : bf00
> > Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> > Control: 00093177 Table: 0e4c DAC: 0051
> > Process systemd-modules (pid: 89, stack limit = 0x9fccc8dc)
> > Stack: (0xce44fe58 to 0xce45)
> > fe40:
> > cf1b05b8
> > fe60: 0001 ce47cf08 bf002754 c07ae5d8 d0a2a484 bf002060 bf0004f8
> >
> > fe80: b6d17910 c017cf1c ce47cf00 d0a29000 ce47cf00 ce44ff34 14fc
> >
> > fea0: bf00025c 0001 6e72656b
> > 6c65
> > fec0:
> >
> > fee0: c0ac9048 7fff
> >
> > ff00: b6d17910 0005 017b c0009208 ce44e000 b6ebfe54
> > c008562c
> > ff20: 7fff 0003 cefd28f8 0001 d0a29000 14fc
> >
> > ff40: d0a292cb d0a29380 d0a29000 14fc d0a29f0c d0a29d90 d0a29a60
> > 0520
> > ff60: 0710 0718 0826 0708
> > 0023
> > ff80: 0024 001c 0016 c0ac9048 0041c620
> >
> > ffa0: c0009000 0041c620 0005 b6d17910
> >
> > ffc0: 0041c620 017b 0041f078 004098b0
> > b6ebfe54
> > ffe0: bedb6bc8 bedb6bb8 b6d0f91c b6c945a0 6010 0005
> >
> > [] (frob_text.constprop.0) from []
> > (load_module+0x14b4/0x1d28)
> > [] (load_module) from [] (sys_finit_module+0xa0/0xc4)
> > [] (sys_finit_module) from []
> > (ret_fast_syscall+0x0/0x50)
> > Exception stack(0xce44ffa8 to 0xce44fff0)
> > ffa0: 0041c620 0005 b6d17910
> >
> > ffc0: 0041c620 017b 0041f078 004098b0
> > b6ebfe54
> > ffe0: bedb6bc8 bedb6bb8 b6d0f91c b6c945a0
> > Code: e7f001f2 e5931008 e1110002 0a
Re: [linux-yocto] [PATCH] modules: always page-align module section allocations
[[linux-yocto] [PATCH] modules: always page-align module section allocations]
On 16/08/2019 (Fri 15:36) zhe...@windriver.com wrote:
It helps maintainers if the version is embedded in the subject, like:
[PATCH v4.18] modules: always page-align module section
> From: Jessica Yu
>
> Some arches (e.g., arm64, x86) have moved towards non-executable
> module_alloc() allocations for security hardening reasons. That means
> that the module loader will need to set the text section of a module to
> executable, regardless of whether or not CONFIG_STRICT_MODULE_RWX is set.
>
> When CONFIG_STRICT_MODULE_RWX=y, module section allocations are always
> page-aligned to handle memory rwx permissions. On some arches with
> CONFIG_STRICT_MODULE_RWX=n however, when setting the module text to
> executable, the BUG_ON() in frob_text() gets triggered since module
> section allocations are not page-aligned when CONFIG_STRICT_MODULE_RWX=n.
> Since the set_memory_* API works with pages, and since we need to call
> set_memory_x() regardless of whether CONFIG_STRICT_MODULE_RWX is set, we
> might as well page-align all module section allocations for ease of
> managing rwx permissions of module sections (text, rodata, etc).
>
> Fixes: 2eef1399a866 ("modules: fix BUG when load module with rodata=n")
> Reported-by: Martin Kaiser
> Reported-by: Bartosz Golaszewski
> Tested-by: David Lechner
> Tested-by: Martin Kaiser
> Tested-by: Bartosz Golaszewski
> Signed-off-by: Jessica Yu
>
> commit38f054d549a869f22a02224cd276a27bf14b6171 upstream
Normally we put this right at the top of the long log. Also this commit
ID appears bogus - it does not exist in mainline.
Also it seems very odd that the block of Signed-off lines are stuck in
the middle of the long log.
>
> When loading modules with CONFIG_ARCH_HAS_STRICT_MODULE_RWX enabled and
> CONFIG_STRICT_MODULE_RWX disabled, the memory allocated for modules would
> not be page-aligned and cause the following BUG during frob_text.
>
> [ cut here ]
> kernel BUG at kernel/module.c:1907!
> Internal error: Oops - BUG: 0 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 89 Comm: systemd-modules Not tainted 5.3.0-rc2 #1
> Hardware name: ARM-Versatile (Device Tree Support)
> PC is at frob_text.constprop.0+0x2c/0x40
> LR is at load_module+0x14b4/0x1d28
> pc : []lr : []psr: 2013
> sp : ce44fe58 ip : fp :
> r10: r9 : ce44feb8 r8 :
> r7 : 0001 r6 : bf00032c r5 : ce44ff40 r4 : bf000320
> r3 : bf000400 r2 : 0fff r1 : 0220 r0 : bf00
> Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 00093177 Table: 0e4c DAC: 0051
> Process systemd-modules (pid: 89, stack limit = 0x9fccc8dc)
> Stack: (0xce44fe58 to 0xce45)
> fe40: cf1b05b8
> fe60: 0001 ce47cf08 bf002754 c07ae5d8 d0a2a484 bf002060 bf0004f8
> fe80: b6d17910 c017cf1c ce47cf00 d0a29000 ce47cf00 ce44ff34 14fc
> fea0: bf00025c 0001 6e72656b 6c65
> fec0:
> fee0: c0ac9048 7fff
> ff00: b6d17910 0005 017b c0009208 ce44e000 b6ebfe54 c008562c
> ff20: 7fff 0003 cefd28f8 0001 d0a29000 14fc
> ff40: d0a292cb d0a29380 d0a29000 14fc d0a29f0c d0a29d90 d0a29a60 0520
> ff60: 0710 0718 0826 0708 0023
> ff80: 0024 001c 0016 c0ac9048 0041c620
> ffa0: c0009000 0041c620 0005 b6d17910
> ffc0: 0041c620 017b 0041f078 004098b0 b6ebfe54
> ffe0: bedb6bc8 bedb6bb8 b6d0f91c b6c945a0 6010 0005
> [] (frob_text.constprop.0) from []
> (load_module+0x14b4/0x1d28)
> [] (load_module) from [] (sys_finit_module+0xa0/0xc4)
> [] (sys_finit_module) from [] (ret_fast_syscall+0x0/0x50)
> Exception stack(0xce44ffa8 to 0xce44fff0)
> ffa0: 0041c620 0005 b6d17910
> ffc0: 0041c620 017b 0041f078 004098b0 b6ebfe54
> ffe0: bedb6bc8 bedb6bb8 b6d0f91c b6c945a0
> Code: e7f001f2 e5931008 e1110002 0a01 (e7f001f2)
> ---[ end trace e904557128d9aed5 ]---
>
> Signed-off-by: He Zhe
> ---
> This is for linux-yocto-dev all branches.
The version information is important, and shouldnt be hidden down here.
If you put it within the [PATCH ] square bracket section, the
maintainer/merger person will see it and the "git am" will throw it away
once applied.
Paul.
--
>
> kernel/module.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 5933395..cd8df51 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -64,1
