Linux驱动开发错误:module license ‘unspecified’ taints kernel.

原文链接: http://blog.csdn.net/zengxianyang/article/details/50710695

前言

今天我要来说说在Linux驱动开发中Makefile编写规则的问题。其实这是驱动开发中的基础性的问题,怪自己基础不够扎实啊,犯了这样的低级错误。写这篇文章让自己巩固一下基础吧,唯有厚积,才能薄发!扎实的编程基础,是一个底层软件工程师应该具备的素质,这样才能年薪百万,迎娶白富美,走上人生巅峰!麻痹,老子又在意淫了,女朋友在哪里都还不知道,说多了都是泪,言归正传!别装逼了!讲正事!

1 Linux驱动Makefile编写规则介绍

1.1 Linux驱动Makefile实例讲解

这里,我们简单的举一个hello驱动的Makefile,来讲解驱动开发中,makefile的编写规则
[objc] view plain copy

 在CODE上查看代码片派生到我的代码片

  1. obj-m := hello.o
  2. hello-obj := hello_main.o file1.o file2.o
  3. KERNELDR := /usr/src/linux-2.6.26
  4. PWD := $(shell pwd)
  5. modules:
  6.     $(MAKE) -C $(KERNELDR) M=$(PWD) modules
  7. moduels_install:
  8.     $(MAKE) -C $(KERNELDR) M=$(PWD) modules_install
  9. clean:
  10.     rm -rf *.o *~ core .depend .*.cmd *.ko *.mod.c .tmp_versions
(1)obj-m := hello.o
表面驱动模块从目标文件hello.o建立,从目标文件建立后,模块的名字为hello.ko。
  (2) module-objs:如果模块由N个文件组成,那么其他文件就应该描述如下:module-objs:= file1.o file2.o,由于我们的模块叫做hello,在这个例子中应该写为hello-objs 。
(3)KERDIR  := /usr/src/linux-2.6.26
用来定位用于编译驱动的内核源码的目录位置。
(4)-C表示kernel source目录,在/lib/modules/<uname -r’>/build,在那里可以找到kernel的最高lenvel的makefile,M=表示在建立模块target的时候,makefile回归到我  们模块程序的目录。

2 驱动加载错误:module license ‘unspecified’ taints kernel

当时我的液晶驱动是由多个C文件组成的一个模块,但是由于多个C文件当中的一个xxx.o文件和模块目标文件xxx.o重名了,所以导致这个错误的,当时加载驱动的时候如下错误:
[objc] view plain copy

 在CODE上查看代码片派生到我的代码片

  1. root@Phoenix /root#insmod mxc_elcdif_fb.ko
  2. mxc_elcdif_fb: module license ‘unspecified’ taints kernel.
  3. Disabling lock debugging due to kernel taint
  4. mxc_elcdif_fb: Unknown symbol self_pid (err 0)
  5. mxc_elcdif_fb: Unknown symbol gpio_free (err 0)
  6. mxc_elcdif_fb: Unknown symbol drv_version (err 0)
  7. mxc_elcdif_fb: Unknown symbol reset_gpio (err 0)
  8. mxc_elcdif_fb: Unknown symbol disp_init_gpio (err 0)

2.1 解决办法

如果我们有多个c文件,可以在test-objs参数中加入他们的obj文件。接下来就是make了,编译后,生成hello.o文件和hello.ko,还有hello.mod.c及其obj文件,Module.markers Module.sysvers Modules.order 文件。

我们对多个*.c文件情况做一个说明:我们希望创建一个模块的名字叫做hello,我们有三个*.c文件,分别为hello.c, file1.c和file2.c。这样是有问题的,因为在Makefile中obj-m := hello.o,这是指定模块的名称, hello-objs := file1.o file2.o hello.o,这里是说hello模块包括的的obj文件,如果我们在里面不填写hello.o,那么实际并没有编译hello.c,而是在CC[M] file1.o和file2.o,通过LD[M]得到模块hello.o,如果我们在这里填写了hello.o,那么在obj-m和hello-objs中都含有hello.o,对make来讲会产生循环和混淆,因此也不能这样书写。如果我们由多个C文件来构造一个模块,那么C文件的名字不能和模块名字一样,在这个例子中我们可以将hello.c改名为hello_main.c,在Makefile中obj-m := hello.o,hello-objs = file1.o file2.o hello_main.o。

2016 年谷歌开源了这些超酷炫的项目

原文链接: http://top.jobbole.com/35954/

开放源代码软件让 Google 能够无需重新发明轮子就能够快速有效地进行开发,也让我们能够集中注意力来解决新问题。我们知道,支持开源,就是站在了巨人的肩膀上,所以 Google 员工能够轻松地将他们在内部工作的项目作为开放源代码发布。

我们已经发布了超过2000万行的开源代码,包括 Android,Angular,Chromium,Kubernetes 和 TensorFlow 等项目。 我们的版本还包括许多您可能不熟悉的项目,例如 Cartographer,Omnitone 和 Yeoman。

回顾我们在 2016 年开源的项目,有很多令人兴奋的事情。 我们发布了很多开源软件、硬件和数据集,来看看今年的一些版本。

 

负载均衡系统 Seesaw

Seesaw是由我们网络可靠性工程师用 Go 语言开发的基于 Linux 虚拟服务器的负载平衡平台,就像所有好的项目一样,这个项目也是为了解决实际问题而产生的。

Seesaw发布的博客中这样写道:“我们需要能够处理单播(unicast)和任播(anycast)虚拟 IP (VIPs) 流量,使用 NAT 和 DSR (也被称为 DR) 执行负载均衡,执行针对后端的健康检查。特别是,我们需要一个容易管理的平台,可以自动部署配置的变化。在评估了一些包括现有的开源项目的平台之后,我们没能找出一个能够满足我们所有需求的平台,所以我们决定自己着手开发一个可靠和可伸缩的负载均衡平台。”

它让我们提高了服务可用性并降低了管理开销。我们很高兴能够把它分享出来,希望其他企业也能够从中受益。

 

供应商安全评估调查问卷 VSAQ

VSAQ (Vendor Security Assessment Questionnaire,供应商安全评估调查问卷)是一种能够自适应式评估多种供应商安全和隐私防护策略的评估调查问卷。

我们每年对数百家供应商的安全性进行评估,因此开发了 VSAQ 来自动化大部分初始信息的收集。许多供应商发现我们的问卷直观灵活,所以我们决定分享出来。 VSAQ 框架包括四个可扩展的问卷模板,涵盖Web应用程序,隐私程序,基础设施以及物理和数据中心安全。

http://static.cnbetacdn.com/article/2016/0309/baa75ec0cfcb2de.png

 

Nest开源的Thread协议 OpenThread

Nest 开源的 OpenThread 是基于其 Thread 协议实现的,通过 6LoWPAN 标准连接的智能家居网络。OpenThread 的开发由 ARM,微软,高通,德州仪器和其他主要供应商支持。

OpenThread 是 Nest 主要负责的,而不是 Thread Group。通过 OpenThread,Nest 希望将Nest 产品中所用的技术在更多供应商和制造商中广泛采用,以加速智能产品家居网络产品的开发进展。随着越来越多的供应商运用 Thread,制造商可以有机会选择一个成熟的网络技术,而不需要创建它们自己的产品,消费者将会有越来越多安全可靠的相关产品可以选择。

 

创作艺术和谱写曲子的机器智能 Magenta

我们可以使用机器学习创造引人注目的艺术和音乐吗?Magenta 可以帮你实现,它是 Google Brain 团队建立的一个基于 TensorFlow 的项目,目的是提高音乐和艺术生成的机器智能的艺术水平,并建立一个艺术家,程序员和机器学习研究者的协作社区。

点这里听听谷歌人工智能的第一首歌曲

 

普通耳机实现 VR 中的 3D 全景音效 Omnitone

虚拟现实(VR)并不像没有空间音频一样沉浸,而且许多VR开发都是在专有平台上进行的。 Omnitone 是一个开放的图书馆,由 Chrome 小组成员为浏览器带来空间音频。Omnitone 基于标准的 Web Audio API,提供身临其境的体验,可以与 WebVR 等项目一起使用。

原理图:

Google发布Omnitone ,为VR音频制作带来了什么改变?

 

实验记录应用 Science Journal

今天的智能手机有很多传感器,可以告诉我们周围的很多有趣的事情。通过这款应用,你可以利用你手机中的各种传感器来测量您的环境,如光和声音,因此您可以绘制您的数据,记录您的实验,并组织您的问题和想法。让手机成为一个强大的研究实验室。

我们推出了 Science Journal 是为了帮助教育工作者、学生和公民科学家利用这些传感器。

 

ROS 系统支持的 SLAM 库 Cartographer

Cartographer 是一个利用ROS系统支持的 2D 和 3D SLAM(simultaneous localization and mapping)库。 这个库库组合来自各种传感器的数据来计算定位和地图环境。

SLAM 是众多自动驾驶平台的重要组件,比如自动驾驶汽车、仓库中的自动叉车、扫地机器人、UAVs 等。在产业界和学术界常见的传感器配置上,Cartographer 能实时建立全局一致的地图。

文章部分内容编译自:opensource.com

内核符号表详解——如何在module中利用内核符号

 

原文链接: http://blog.csdn.net/trochiluses/article/details/9446955

 

前言:在内核开发中,有时候我们必须检查某些内核状态,或者我们想冲用某些内核功能,我们需要得到(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中文件的代码:

  1. static const struct file_operations kallsyms_operations = {
  2.         .open = kallsyms_open,
  3.         .read = seq_read,
  4.         .llseek = seq_lseek,
  5.         .release = seq_release_private,
  6. };
  7. static int __init kallsyms_init(void)
  8. {
  9.         proc_create(“kallsyms”, 0444, NULL, &kallsyms_operations);
  10.         return 0;
  11. }
  12. 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.

  1. static const struct seq_operations kallsyms_op = {
  2.         .start = s_start,
  3.         .next = s_next,
  4.         .stop = s_stop,
  5.         .show = s_show
  6. };

因此,为了我们的目标,我们关心s_start() and s_next().它们都调用了update_iter(),而update_iter()的核心是get_ksymbol_mod(),紧跟着的是get_ksmbol_mod(),最后是module_get_kallsym().这些函数都在kernel/module.c中。

  1. int module_get_kallsym(unsigned int symnum, unsigned long *value, char *type,
  2.                         char *name, char *module_name, int *exported)
  3. {
  4.         struct module *mod;
  5.         preempt_disable();
  6.         list_for_each_entry_rcu(mod, &modules, list) {
  7.                 if (symnum < mod->num_symtab) {
  8.                         *value = mod->symtab[symnum].st_value;
  9.                         *type = mod->symtab[symnum].st_info;
  10.                         strlcpy(name, mod->strtab + mod->symtab[symnum].st_name,
  11.                                 KSYM_NAME_LEN);
  12.                         strlcpy(module_name, mod->name, MODULE_NAME_LEN);
  13.                         *exported = is_exported(name, *value, mod);
  14.                         preempt_enable();
  15.                         return 0;
  16.                 }
  17.                 symnum -= mod->num_symtab;
  18.         }
  19.         preempt_enable();
  20.         return -ERANGE;
  21. }

在 module_get_kallsym()中,它迭代了所有的模块和符号。五个性质是指定的值。value是这个符号的地址,type是符号类型,name是符号名字,module_name是模块名字(如果这个模块没有被编进内核;反之它就是空);exported表明这个符号是否是exported。那么为什么这里有很多local的符号呢?我们来看看s_low()

  1. if (iter->module_name[0]) {
  2.                 char type;
  3.                 /*
  4.                  * Label it “global” if it is exported,
  5.                  * “local” if not exported.
  6.                  */
  7.                 type = iter->exported ? toupper(iter->type) :
  8.                                         tolower(iter->type);
  9.                 seq_printf(m, “%0*lx %c %s\t[%s]\n”,
  10.                            (int)(2 * sizeof(void *)),
  11.                            iter->value, type, iter->name, iter->module_name);
  12.         } else
  13.                 seq_printf(m, “%0*lx %c %s\n”,
  14.                            (int)(2 * sizeof(void *)),
  15.                            iter->value, iter->type, iter->name);

好了,现在明白了吧,所有的这些符号都是C语言中的全局变量,但是者有exported 符号被打上“global”的标签。在迭代结束之后,我们来看看/proc/kallsyms中的 内容。

3.如何得到符号表

这里,得到指的是可读,可写,可执行,我们来看一看以下模块:

  1. #include <linux/module.h>
  2. #include <linux/init.h>
  3. #include <linux/kernel.h>
  4. #include <linux/jiffies.h>
  5. MODULE_AUTHOR(“Stephen Zhang”);
  6. MODULE_LICENSE(“GPL”);
  7. MODULE_DESCRIPTION(“Use exported symbols”);
  8. static int __init lkm_init(void)
  9. {
  10.     printk(KERN_INFO “[%s] module loaded.\n”, __this_module.name);
  11.     printk(“[%s] current jiffies: %lu.\n”, __this_module.name, jiffies);
  12.     return 0;
  13. }
  14. static void __exit lkm_exit(void)
  15. {
  16.     printk(KERN_INFO “[%s] module unloaded.\n”, __this_module.name);
  17. }
  18. module_init(lkm_init);
  19. 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)

How?! 它没有被定义在内核源代码中,那么在insmod的时候被链接到哪里呢?不要慌张,你注意到编译内核的时候产生的临时文件hello.mod.c了吗?这里有__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为例,上代码:

  1. #include <linux/module.h>
  2. #include <linux/kallsyms.h>
  3. #include <linux/string.h>
  4. MODULE_LICENSE(“GPL”);
  5. MODULE_DESCRIPTION(“Access non-exported symbols”);
  6. MODULE_AUTHOR(“Stephen Zhang”);
  7. static int __init lkm_init(void)
  8. {
  9.     char *sym_name = “resume_file”;
  10.     unsigned long sym_addr = kallsyms_lookup_name(sym_name);
  11.     char filename[256];
  12.     strncpy(filename, (char *)sym_addr, 255);
  13.     printk(KERN_INFO “[%s] %s (0x%lx): %s\n”, __this_module.name, sym_name, sym_addr, filename);
  14.     return 0;
  15. }
  16. static void __exit lkm_exit(void)
  17. {
  18. }
  19. module_init(lkm_init);
  20. 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错误。然而,你可以关掉保护,从而向只读空间写入东西。遵循以下操作,基本思想就是改变页属性。

  1. int set_page_rw(long unsigned int _addr)
  2. {
  3.     struct page *pg;
  4.     pgprot_t prot;
  5.     pg = virt_to_page(_addr);
  6.     prot.pgprot = VM_READ | VM_WRITE;
  7.     return change_page_attr(pg, 1, prot);
  8. }
  9. int set_page_ro(long unsigned int _addr)
  10. {
  11.     struct page *pg;
  12.     pgprot_t prot;
  13.     pg = virt_to_page(_addr);
  14.     prot.pgprot = VM_READ;
  15.     return change_page_attr(pg, 1, prot);
  16. }

 

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

 

本文中,我们首先挖掘了内核源码来找到内核符号表是如何产生的。接着我们学习了在我们的模块中如何利用导出的内核符号。最后我们学习了如何在模块中利用所有内核符号的技巧。