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
| ||
|
Date: Wed, 25 Nov 2015 12:09:13 +1030 From: Rusty Russell <rusty@...tcorp.com.au> To: Miroslav Benes <mbenes@...e.cz> Cc: linux-kernel@...r.kernel.org, Miroslav Benes <mbenes@...e.cz> Subject: Re: [PATCH] module: keep percpu symbols in module's symtab Miroslav Benes <mbenes@...e.cz> writes: > 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. Yes, you should do this instead, I think. Cheers, Rusty. -- 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/
Powered by blists - more mailing lists