戴君毅: Linus都要再三修正的max()宏是怎样演变的

2019-11-10 16:52:00 浏览数 (1)

陈莉君老师写在前面:

"本学期给研一小鲜肉们上Linux内核课程,发现内核代码具有激活学生们潜质的功效。前一段时间贺东升同学对内核第一宏的分析,不仅在读者中产生共鸣,更重要的是贺同学内在沉睡的潜质被激活,而max()宏的深入分析,让梁同学不能罢手,在深入代码的过程中,也是不断的唤醒沉睡的潜力。本篇对max()宏的全面梳理,我看完第一稿,以为是老手所为,实际上,也是菜鸟戴同学从旁观者给梁同学的一臂之力,使得整个的max()宏的分析和演变有了一个完满的结局。"

- 陈莉君 西安邮电大学教授

(点击回顾内核第一宏)

大家好,又与大家见面了,今天我们继续聊一聊关于Linux内核中的max()宏。

在前两篇文章中,小编的同门@梁金荣 同学已经非常贴心地将Linux内核中的max()宏为我们逐项拆解,今天我们在之前两篇文章的基础上继续探讨一下max()宏的发展历史。

ps:小编也是刚接触Linux内核的小白,如果有问题希望大家留言指正~

想必大家对老版本内核中的max()宏已经有了深刻印象:前面的文章已经详细地说明了一个max宏是如何从

代码语言:javascript复制
 #define max(x, y) (x) > (y) ? (x) : (y);

转换成下面这样的(内核版本2.6)

代码语言:javascript复制
#define max(x,y) ({                  
typeof(x) _max1 = (x);           
typeof(y) _max2 = (y);           
(void) (&_max1 == &_max2);       
_max1 > _max2 ? _max1 : _max2; })

具体请阅读【Linux内核中max()宏的奥妙何在?(一) 】 点击访问

其实很多资料显示max宏是这样的...

代码语言:javascript复制
#define max(x, y) ({                
    typeof(x) _x = (x);             
    typeof(y) _y = (y);             
    (void) (&_x == &_y);           
    _x > _y2 ? _x : _y; })

看出来差距了吗?其实就是把变量 _ x换成了_ max1, _ y换成了_max2

为什么要这样做呢?

假如内核程序员调用max()宏来比较如下两个数的大小时,这会导致意想不到的后果:

代码语言:javascript复制
int x = 3; int _x =6;
max(x, _x)

Linux内核在设计max()宏时使变量名尽量变得复杂,同时要保证"见名知义"。这样做确实很大程度上避免了一些重名导致的安全问题,因为很少有程序员会这样调用:

代码语言:javascript复制
max(x, _max1)

但这明显属于"换汤不换药"的解决方案,内核设计者不应该苛求程序员定义一个变量名称时考虑这么多。

既然重名问题可能引起上述问题,那么有机制可以使得命名永远不会重复吗?内核开发者朝这个方向做出了努力,小编查阅了4.15.9版本内核源码,发现max()宏悄然发生了变化:

代码语言:javascript复制
/**
 * max - return maximum of two values of the same or compatible types 
 * @x: first value 
 * @y: second value */
#define max(x, y)                     
   __max(typeof(x), typeof(y),             
   __UNIQUE_ID(max1_), __UNIQUE_ID(max2_),     
   x, y)

#define __max(t1, t2, max1, max2, x, y) ({        
    t1 max1 = (x);                      
    t2 max2 = (y);                      
    (void) (&max1 == &max2);                
    max1 > max2 ? max1 : max2; })

<linux/gcc-compiler.h>中给出了 __UNIQUE_ID 的定义

代码语言:javascript复制
/* Indirect macros required for expanded argument pasting, eg. __LINE__. */
#define ___PASTE(a,b) a##b
#define __PASTE(a,b) ___PASTE(a,b)

#define __UNIQUE_ID(prefix) __PASTE    
(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)

通过代码,我们可以大概了解内核是如何PASTE一个ID给待比较大小的两个数。这里给出GCC文档相关原文

COUNTERThis macro expands to sequential integral values starting from 0. In conjunction with the ## operator, this provides a convenient means to generate unique identifiers. Care must be taken to ensure that COUNTER is not expanded prior to inclusion of precompiled headers which use it. Otherwise, the precompiled headers will not be used.

从GCC文档可以看出每个值"Unique"的名称是通过GCC编译器中的 COUNTER 和 运算符 ## 实现的。

至此,因为重名而引起max()宏异常已经成为了历史,因为每个数字都得到了独一无二的名称。

但是,这样并不完美

为什么呢?(这个关子卖的真是僵硬,上一篇大家都见识过了最新版本的max()宏了嘛,肯定知道介个并不是最新版本的max()宏啦)

了解过GNU C的同学应该知道有一个变长数组(VLA)这种神奇的存在,VLA在运行时其长度是不确定的,每次调用它都需要额外计算它的长度,增加了开销;更严重的是,内核的堆栈大小受限,而随意的使用VLA可能会使其长度飞速增长,攻击者如果可以以某种方式控制VLA大小,那么后果是可怕的。(想要深入了解GNU C的同学请访问http://www.nongnu.org/c-prog-book/online/)

所以内核设计者不鼓励在内核空间中使用VLA,但并没有禁止它。

不久之前,Linus宣称“使用VLA是愚蠢的!”并将VLA从内核移除提上了日程.……

强大的GNU社区推出了Wvla工具提供GCC -Wvla选项,该选项可以在程序员声明VLA时发出警告

然而不久又有人发现了BUG。。。他给Linus发了邮件:

The "sym" calculation is actually a fixed size, but since the max() macro uses some extensive tricks for safety, it ends up looking like a variable size. This replaces max() with a simple max macro which is sufficient for the calculation of the array size 他在声明一个定长数组的时候(看起来像VLA)使用GCC -Wvla时得到了警告,并认为GCC不够聪明,无法分辨VLA和定长数组。

然而Linus就是Linus,大神就是大神,他迅速找出了问题所在,并回复了邮件:

C标准在“常量值”和“常量表达式”之间进行了区分。数组维度必须是常量表达式,但max()宏的设计不符合这个规范。

于是,修订版本的max()宏出现了,请欣赏(内核版本4.8.5)

代码语言:javascript复制
#define __single_eval_max(t1, t2, max1, max2, x, y) ({    
t1 max1 = (x);                    
t2 max2 = (y);                    
(void) (&max1 == &max2);            
max1 > max2 ? max1 : max2; })

#define __max(t1, t2, x, y)                
__builtin_choose_expr(__builtin_constant_p(x) &&    
    __builtin_constant_p(y),        
    (t1)(x) > (t2)(y) ? (t1)(x) : (t2)(y),      
    __single_eval_max(t1, t2,           
        __UNIQUE_ID(max1_),         
        __UNIQUE_ID(max2_),         
        x, y))
#define max(x, y)    __max(typeof(x), typeof(y), x, y)

可以看到内核代码中含有 “__builtin_constant” 字样,这说明对判断常量这件事做出了足够的努力,由于这个版本的max()宏使用了太多“逻辑短路”的宏技巧,对旧的编译器没有很好的支持。所以还需要继续迭代,但经过内核开发者的不断提交patch,目前至少声明一个定长数组时不会再偶然地发出“VLA警告”。

(对 __builtin 有兴趣的小伙伴请访问 https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

最新的max()

在内核邮件列表中,有一篇主题为【3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91 oopses on s390】 的邮件,Sebastian Ott发出抱怨,在他的机器上使用 min_not_zero()出现了问题

Kees Cook建议他使用适用于s390的GCC版本;而Linus看出了问题所在,他有过这方面的经验:又是老问题——重名!

随后Linus修复了该问题,然而在后续交流中Sebastian Ott继续吐槽:"......and our_UNIQUEID() macro is garbage anyway......" (小编吐槽环节:用了小众机器就不要乱骂别人garbage啊。。)

Linus作出回复,并深刻反思了错误出现的原因:

从此,_UNIQUE_ID()这个宏的使用需要变得谨慎,当然,max()也需要重写。

所以,最新的max()应运而生

最后请大家再欣赏一下max(),详细分解请参考公众号上一篇文章:

【大神Linus对这个宏怎么看?】点击访问

代码语言:javascript复制
#define __typecheck(x, y) 
	(!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))

#define __is_constexpr(x) 
	(sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8)))

#define __no_side_effects(x, y) 
	(__is_constexpr(x) && __is_constexpr(y))

#define __safe_cmp(x, y) 
	(__typecheck(x, y) && __no_side_effects(x, y))

#define __cmp(x, y, op)	((x) op (y) ? (x) : (y))

#define __cmp_once(x, y, unique_x, unique_y, op) ({	
    typeof(x) unique_x = (x);		
    typeof(y) unique_y = (y);		
    __cmp(unique_x, unique_y, op); })

#define __careful_cmp(x, y, op) 
    __builtin_choose_expr(__safe_cmp(x, y), 
    __cmp(x, y, op), 
    __cmp_once(x, y, __UNIQUE_ID(__x), __UNIQUE_ID(__y), op))

#define max(x, y)	__careful_cmp(x, y, >)

目前,Linux内核最新版本为5.3.1,该版本中max()似乎没有再进行修改。

结束语

从发现bug到修改bug,再上升到“机制”与“策略”,不断迭代,拥抱变化。Linux内核作为最大的开源项目,值得我们学习和探索。

0 人点赞