linux-kernel - [PATCH] module: keep percpu symbols in module's symtab

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1448024043-29578-1-git-send-email-mbenes@suse.cz>
Date:	Fri, 20 Nov 2015 13:54:03 +0100
From:	Miroslav Benes <mbenes@...e.cz>
To:	rusty@...tcorp.com.au
Cc:	linux-kernel@...r.kernel.org, Miroslav Benes <mbenes@...e.cz>
Subject: [PATCH] module: keep percpu symbols in module's symtab

Currently, percpu symbols from .data..percpu ELF section of a module are
not copied over and stored in final symtab array of struct module.
Consequently such symbol cannot be returned via kallsyms API (for
example kallsyms_lookup_name). This can be especially confusing when the
percpu symbol is exported. Only its __ksymtab et al. are present in its
symtab.

The culprit is in layout_and_allocate() function where SHF_ALLOC flag is
dropped for .data..percpu section. There is in fact no need to copy the
section to final struct module, because kernel module loader allocates
extra percpu section by itself. Unfortunately only symbols from
SHF_ALLOC sections are copied (see is_core_symbol()).

The patch restores SHF_ALLOC flag for original percpu section. The
section with its symbols is thus copied over, but not otherwise used.
st_value of percpu symbols points to correct newly allocated section
thanks to correction in simplify_symbols().

Signed-off-by: Miroslav Benes <mbenes@...e.cz>
---

I don't deem the solution nice. The other one I came up with was to hack
is_core_symbol() to copy percpu symbols. There is a catch though.
Elf_Sym's st_shndx is an index to an associated section. If we do not
preserve .data..percpu section the index would be invalid. But this is
similar to other symbols as well I guess. The index is never valid after
move_module(), right? The only relevant check I found in the kernel is
in get_ksymbol() - 'st_shndx == SHN_UNDEF'. So it could be harmless.

On the other hand copying of percpu section is simple and should not
break anything.

What do you think?

Thanks,
Miroslav

 kernel/module.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index 8f051a106676..e489cd7a8d53 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3108,9 +3108,6 @@ static struct module *layout_and_allocate(struct load_info *info, int flags)
 	if (err < 0)
 		return ERR_PTR(err);

-	/* We will do a special allocation for per-cpu sections later. */
-	info->sechdrs[info->index.pcpu].sh_flags &= ~(unsigned long)SHF_ALLOC;
-
 	/* Determine total sizes, and put offsets in sh_entsize.  For now
 	   this is done generically; there doesn't appear to be any
 	   special cases for the architectures. */
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/