前言：在内核开发中，有时候我们必须检查某些内核状态，或者我们想冲用某些内核功能，我们需要得到（read，write，exe）内核符号。本文主要为你介绍内核如何保存这些符号表，我们怎样应用这些内核符号表。本文仅仅是阅读内核源码的一个guide，通过阅读内核源码，我们将有更深入的理解。
1.什么是内核符号
先看基础知识：在编程语言中，符号指的是一个变量或者函数。更一般地说，符号是一个代表着内存中指定空间的名称，这个空间存储着数据（可读或者可写的变量）或者指令（可以执行的函数）。为了让不同的内核功能单元能够更好地协同工作，linux内核中有着数以千计的内核符号。一个全局变量在一个函数之外定义。一个全局函数声明的时候不能带有inline和static。所有的全局符号在/proc/kallsyms中列出，如下：
$ tail /proc/kallsyms
ffffffff81da9000 b .brk.dmi_alloc
ffffffff81db9000 B __brk_limit
ffffffffff600000 T vgettimeofday
ffffffffff600140 t vread_tsc
ffffffffff600170 t vread_hpet
ffffffffff600180 D __vsyscall_gtod_data
ffffffffff600400 T vtime
ffffffffff600800 T vgetcpu
ffffffffff600880 D __vgetcpu_mode
ffffffffff6008c0 D __jiffies
这是一个nm输出的形式，第一列是符号地址，第二列是符号表，详细信息参见 “man nm”。一般来说，这是“nm vmlinux”的输出结果。然而，这个符号表中的一些条目来源于可加载内核模块，那么这些条目是如何被列出来的呢？我们来看看这个符号表是怎么产生的。
2./proc/kallsyms是如何产生的
如同我们在前两篇文章中看到的那样：procfs文件是在内核中读取的，所以不要在磁盘上寻找，而应该去内核源码中寻找答案。首先，我们找到产生/kernel/kallsyms.c中文件的代码：
static const struct file_operations kallsyms_operations = {
.open = kallsyms_open,
.read = seq_read,
.llseek = seq_lseek,
.release = seq_release_private,
};
static int __init kallsyms_init(void)
{
proc_create("kallsyms", 0444, NULL, &kallsyms_operations);
return 0;
}
device_initcall(kallsyms_init);
在创建这些文件的时候，内核将 open()和 kallsyms_open()关联起来, read()->seq_read(), llseek()->seq_lseek() and release()->seq_release_private(). 这里，我们可以看到：这个文件是一个序列文件。
对这个序列文件的详细讨论已经超出了本文的范畴。在内核文档中，有关于这个的很好理解的描述，如果你不了解什么是sequence文件，可以参考 Documentation/filesystems/seq_file.txt。简单地说，因为proc_read_t篇幅有限，内核引进了sequence 文件来给用户提供大量的信息。
回到源码，在kallsyms_open（）中，它仅仅创建和重置了对seq_read 操作的迭代器，当然也设置了seq_operations.
static const struct seq_operations kallsyms_op = {
.start = s_start,
.next = s_next,
.stop = s_stop,
.show = s_show
};因此，为了我们的目标，我们关心s_start() and s_next().它们都调用了update_iter(),而update_iter(）的核心是get_ksymbol_mod(),紧跟着的是get_ksmbol_mod(),最后是module_get_kallsym().这些函数都在kernel/module.c中。
int module_get_kallsym(unsigned int symnum, unsigned long *value, char *type,
char *name, char *module_name, int *exported)
{
struct module *mod;
preempt_disable();
list_for_each_entry_rcu(mod, &modules, list) {
if (symnum < mod->num_symtab) {
*value = mod->symtab[symnum].st_value;
*type = mod->symtab[symnum].st_info;
strlcpy(name, mod->strtab + mod->symtab[symnum].st_name,
KSYM_NAME_LEN);
strlcpy(module_name, mod->name, MODULE_NAME_LEN);
*exported = is_exported(name, *value, mod);
preempt_enable();
return 0;
}
symnum -= mod->num_symtab;
}
preempt_enable();
return -ERANGE;
}在 module_get_kallsym()中，它迭代了所有的模块和符号。五个性质是指定的值。value是这个符号的地址，type是符号类型，name是符号名字，module_name是模块名字（如果这个模块没有被编进内核；反之它就是空）；exported表明这个符号是否是exported。那么为什么这里有很多local的符号呢？我们来看看s_low()
if (iter->module_name[0]) {
char type;
/*
* Label it "global" if it is exported,
* "local" if not exported.
*/
type = iter->exported ? toupper(iter->type) :
tolower(iter->type);
seq_printf(m, "%0*lx %c %s\t[%s]\n",
(int)(2 * sizeof(void *)),
iter->value, type, iter->name, iter->module_name);
} else
seq_printf(m, "%0*lx %c %s\n",
(int)(2 * sizeof(void *)),
iter->value, iter->type, iter->name);好了，现在明白了吧，所有的这些符号都是C语言中的全局变量，但是者有exported 符号被打上“global”的标签。 在迭代结束之后，我们来看看/proc/kallsyms中的 内容。
3.如何得到符号表
#include <linux/module.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/jiffies.h>
MODULE_AUTHOR("Stephen Zhang");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Use exported symbols");
static int __init lkm_init(void)
{
printk(KERN_INFO "[%s] module loaded.\n", __this_module.name);
printk("[%s] current jiffies: %lu.\n", __this_module.name, jiffies);
return 0;
}
static void __exit lkm_exit(void)
{
printk(KERN_INFO "[%s] module unloaded.\n", __this_module.name);
}
module_init(lkm_init);
module_exit(lkm_exit);
在这个模块中，我们使用了printk()和jiffies，这些都是来自内核空间的模块。为什么这些模块能够为我们的代码所用呢？因为它们是exported。 你可以认为内核符号在内核源代码中的三个不同层次上。
“static”, and therefore visible only within their own source file
“external”, and therefore potentially visible to any other code built into the kernel itself, and
“exported”, and therefore visible and available to any loadable module.
内核使用两个宏来导出符号：
EXPORT_SYMBOL exports the symbol to any loadable module
EXPORT_SYMBOL_GPL exports the symbol only to GPL-licensed modules.
回到以上的代码，我们可以发现以上的两个符号在以下的内核源码中被导出。
kernel/printk.c:EXPORT_SYMBOL(printk);
kernel/time.c:EXPORT_SYMBOL(jiffies);
除了检查内核源码来判断一个符号是否被导出之外，还有其他的方式来鉴别吗？当然可以。所有被导出的条目有另外一个带有__ksymab_前缀的符号，例如：
ffffffff81a4ef00 r __ksymtab_printk
ffffffff81a4eff0 r __ksymtab_jiffies
Let’s just have another look at the definition of EXPORT_SYMBOL:
/* For every exported symbol, place a struct in the __ksymtab section */
#define __EXPORT_SYMBOL(sym, sec) \
extern typeof(sym) sym; \
__CRC_SYMBOL(sym, sec) \
static const char __kstrtab_##sym[] \
__attribute__((section("__ksymtab_strings"), aligned(1))) \
= MODULE_SYMBOL_PREFIX #sym; \
static const struct kernel_symbol __ksymtab_##sym \
__used \
__attribute__((section("__ksymtab" sec), unused)) \
= { (unsigned long)&sym, __kstrtab_##sym }
#define EXPORT_SYMBOL(sym) \
__EXPORT_SYMBOL(sym, "")
The highlighted line places a struct kernel_symbol __ksymtab_##sym int the symbol table.
还有两外的一个事情值得注意，__this_module既不是一个导出符号，也没有在内核源码中定义。在内核源码中，我们仅仅能找到的关于_this_module的信息就是如下两行代码：
extern struct module __this_module;
#define THIS_MODULE (&__this_module)
struct module __this_module
__attribute__((section(".gnu.linkonce.this_module"))) = {
.name = KBUILD_MODNAME,
.init = init_module,
#ifdef CONFIG_MODULE_UNLOAD
.exit = cleanup_module,
#endif
.arch = MODULE_ARCH_INIT,
};
到目前为止，我们可以看到，在我们的内核模块中，我们仅仅能够使用导出的内核符号；我们需要做的唯一事情就是include相应的内核头文件，或者仅仅使用正确的声明。那么，如果我们想得到其他的内核符号，应该怎么处理呢？尽管引用没有导出的符号并不是一个好注意，这些符号是为了避免别人访问它们从而避免潜在的危险；有一天，仅仅为了满足某些人的好奇心，或者某个对他的行为后果非常清除，我们必须要得到non-exported符号，让我们深入探讨：
5.How to access non-exported symbol
对于内核中的每一个符号，我们都可以在/proc/kallsyms中找到相应的条目，而且可以得到它的地址。因为我们在内核中，我们能够看见任何东西。我们以resume_file为例，上代码：
#include <linux/module.h>
#include <linux/kallsyms.h>
#include <linux/string.h>
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Access non-exported symbols");
MODULE_AUTHOR("Stephen Zhang");
static int __init lkm_init(void)
{
char *sym_name = "resume_file";
unsigned long sym_addr = kallsyms_lookup_name(sym_name);
char filename[256];
strncpy(filename, (char *)sym_addr, 255);
printk(KERN_INFO "[%s] %s (0x%lx): %s\n", __this_module.name, sym_name, sym_addr, filename);
return 0;
}
static void __exit lkm_exit(void)
{
}
module_init(lkm_init);
module_exit(lkm_exit);这里，我们使用kallsyms_lookup_name()而不是解析/proc/kallsyms来找到一个符号的地址。接着，我们把这个地址当成char *，这也是resume_file的类型，然后利用strncpy来读。
看看运行结果：
sudo insmod lkm_hello.ko
dmesg | tail -n 1
[lkm_hello] resume_file (0xffffffff81c17140): /dev/sda6
grep resume_file /proc/kallsyms
ffffffff81c17140 d resume_file
我们做到了！我们可以看见kallsyms_lookup_name()返回的符号地址和 /proc/kallsyms完全相同。同样，你也可以write到一个符号地址，但是对只读地址空间是不行的，不然你会得到一个oops错误。然而，你可以关掉保护，从而向只读空间写入东西。遵循以下操作，基本思想就是改变页属性。
int set_page_rw(long unsigned int _addr)
{
struct page *pg;
pgprot_t prot;
pg = virt_to_page(_addr);
prot.pgprot = VM_READ | VM_WRITE;
return change_page_attr(pg, 1, prot);
}
int set_page_ro(long unsigned int _addr)
{
struct page *pg;
pgprot_t prot;
pg = virt_to_page(_addr);
prot.pgprot = VM_READ;
return change_page_attr(pg, 1, prot);
}
6.2.4与2.6内核关于内核符号表的区别
对于2.4内核和2.6内核的内核符号表是有区别的，2.4内核默认情况下模块中的非静态全局变量以及非静态函数在模块加载后会自动导出到内核符号表中，而2.6内核默认情况下是不会自动导出的，需要显式调用宏EXPORT_SYMBOL才能导出。导出的符号前面一般标注有r标记。可以通过nm -l xx.ko来查看某一个模块里的符号情况。或者通过查看内核符号表文件也行。对于2.4是：cat /proc/ksyms,对于2.6是:cat /proc/kallsyms.
6.Conclusion
本文中，我们首先挖掘了内核源码来找到内核符号表是如何产生的。接着我们学习了在我们的模块中如何利用导出的内核符号。最后我们学习了如何在模块中利用所有内核符号的技巧。
本文来源：谁不小心的CSDN博客 内核符号表详解——如何在module中利用内核符号
1801
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
