| Message ID | 1500039368.5763.12.camel@gmx.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, 2017-07-14 at 18:10 +0200, Peter Zijlstra wrote: > On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote: > > On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote: > > > > Urgh, is for some mysterious reason the __bug_table section of modules > > > ending up in RO memory? > > > > > > I forever get lost in that link magic :/ > > > > +1 > > > > drm.ko > > 20 __bug_table 00000630 0000000000000000 0000000000000000 0004bff3 2**0 > > CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA > > vmlinux > > 15 __bug_table 0000ba84 ffffffff81af26c0 0000000001af26c0 00cf26c0 2**0 > > CONTENTS, ALLOC, LOAD, READONLY, DATA > > > > Danged if I know... um um RELOC business mucks things up? > > Argh, it shouldn't be READONLY for vmlinux either, but apparently that > is working for mysterious reasons. > > Some architectures were in fact complaining that I broke that, and hence > patch: > > b5effd3815cc ("debug: Fix __bug_table[] in arch linker scripts") > > I think we need professional help with this linking stuff, but who to > ask? Andy Lutomirski?
+++ Peter Zijlstra [14/07/17 18:10 +0200]: >On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote: >> On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote: > >> > Urgh, is for some mysterious reason the __bug_table section of modules >> > ending up in RO memory? >> > >> > I forever get lost in that link magic :/ >> >> +1 >> >> drm.ko >> 20 __bug_table 00000630 0000000000000000 0000000000000000 0004bff3 2**0 >> CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA >> vmlinux >> 15 __bug_table 0000ba84 ffffffff81af26c0 0000000001af26c0 00cf26c0 2**0 >> CONTENTS, ALLOC, LOAD, READONLY, DATA >> >> Danged if I know... um um RELOC business mucks things up? > >Argh, it shouldn't be READONLY for vmlinux either, but apparently that >is working for mysterious reasons. If I'm not mistaken, this works because __bug_table falls outside of the RO range as specified in the vmlinux linker script (using x86_64 as the example, that means _text - __end_rodata_hpage_align). mark_rodata_ro() only sets ro memory protections for pages within this range, so __bug_table remains rw in memory despite its Elf section flags. Interestingly enough, my .rodata section is set 'WA' (rw) in vmlinux on my f25 system, so that leads me to think that Elf section flags in vmlinux don't seem to matter much when it comes to setting ro/nx protections.. However, in the module loader it's a different story; we do set page protections strictly according to the section flags, so since __bug_table only has SHF_ALLOC set, it assumes it's a readonly section and gets treated as such. So I would think that Josh's patch would fix this issue. Jessica
--- kernel/Makefile | 2 ++ kernel/foo.c | 15 +++++++++++++++ 2 files changed, 17 insertions(+) --- a/kernel/Makefile +++ b/kernel/Makefile @@ -111,6 +111,8 @@ obj-$(CONFIG_MEMBARRIER) += membarrier.o obj-$(CONFIG_HAS_IOMEM) += memremap.o +obj-m += foo.o + $(obj)/configs.o: $(obj)/config_data.h targets += config_data.gz --- /dev/null +++ b/kernel/foo.c @@ -0,0 +1,15 @@ +#include <linux/module.h> +#include <linux/bug.h> + +static int __init foo_init(void) +{ + printk(KERN_INFO "foo: module loaded\n"); + WARN_ON_ONCE(1); + return 0; +} + +static void __exit foo_exit(void) { } + +module_init(foo_init); +module_exit(foo_exit); +MODULE_LICENSE("GPL");