RTT还需要很长的时间来完善才能用于商业乃至工业现场啊!今天又发现了一个很要命的漏洞,这种漏洞是对临界代码段的理解太随意导致的。
我知道,很多人有时候为了所谓的实时性,都忽略了临界代码段的重要性。但是,如果不仔细推敲代码而随意放任的话,系统会变得异常脆弱!
下面我就来给你分析以下rt_object_find()函数的漏洞。
rt_object_find()函数是通过对象的名称来查找对象,并返回指针。调用该函数之前,线程大都不会关中断来保护rt_object_find(),而该函数自身更是没有临界段保护措施,这样就造成了下面的漏洞:
在遍历链表节点的过程中,node指向当前所检查的对象节点,而在此判断过程中,有可能高优先级线程得到运行,从而导致当前对象节点有可能被删除,这时,对象的链表指针next,prev就指向它自身。之后,CPU上下文回到调用rt_object_find()函数的线程,继续遍历对象链表,结果node = node->next语句总是使node指向它自身,而且符合node != &(information->object_list)条件,因此,for()循环形成了死循环!该函数将无法退出,其结果无法预测!
我是一个思维很严谨的人,总是很小心的对待代码,即使是在单任务软件开发过程中,我也很注意中断函数和main()循环之间的临界代码段问题。希望大家能跟我一样多查看内核代码,尽快完善RTT!
(我的经验都来自ucos源代码,因为国外对RTOS的认证是很严格的,ucos是经过航空级认证的RTOS)
这个确实是问题,其他的几个object函数都加了相应的保护,当时实行这个函数时仅仅是临时的,直接关中断又不忍心,而使用semaphore一类的机制后,那么整个object容器的操作将不能够在中断服务程序中使用。
这个地方确实处理得不太好,而且这个也不是主函数一类的,这个函数还是直接删除掉比较好,这样也比较容易分别进行对待。