SELinux是Security Enhanced Linux的缩写。望文生义的时候还以为是关于黑客啊、攻击啊、漏洞啊之类的事情,这两天在读《SELinux by example》的时候才明白,原来这个东东竟然是用来对付程序员的,准确的说,是为了防止由于程序员的疏忽或错误对系统造成不可预料的伤害。
书中的例子是关于文件/etc/passwd
,碰巧同时在读的《Mastering Perl》的第三章Secure Programming Techniques中也用这个文件举例。后者主要是说明处理外部数据时要格外当心,否则可能导致泄露系统信息。然而,要求每个程序员在写程序的时候都要打起120分的精力来注意安全问题是不现实的,总有这样那样的原因导致安全问题被有意无意的忽略。而且,与其让每个程序单独的考虑安全问题,不如将其放在一个集中的地方,就如同SELinux那样,使用各种规则来保证每个程序只能访问特定的系统资源,以及每种系统资源只能被特定的程序访问。
通俗地讲,即使某些应用程序在运行时被提升为具有root权限以访问某些系统资源,但是由于SELinux的存在,一个具有root权限的程序也不意味着它可以访问任何系统资源,相反,它只能访问那些被SELinux规则允许的系统资源,这样就避免了由于程序员的疏忽或错误而对系统造成伤害。
看到这个我想起一个问题,当然,也是看到你去年的计划总结,呵呵。编译器的优化能力。
以GCC为例,加了-O3后,是否有可能发生下面的情况?
——————–
double i=0.0;
..
..
有if语句判断后,对i赋值(不为0);
..
此后,
通过if语句控制,有很多用到1/i的地方,并且i不再发生变化。
——————–
那么,是否有可能GCC将1/i的计算提前,提前至“有if语句判断后,对i赋值;”的后面,以便后续使用的时候不重复计算?
之所以有这个问题,是在程序里面,我开始对i赋值为0,但后续的计算里面,通过if语句的判断,都没有真正的执行(这也是我想要的),但却报告有算术异常。但如果将前面的i的赋值去掉,仅声明它,就没有这个警告了。
我试图看汇编的结果,无奈,不太懂汇编,没看明白。而且我发现,这个函数如果仅有
double i;
和
double i=0.0;
的差别时,汇编的结果有很大的不同。
如果你说的算术异常是在运行时发生,那么可以尝试关闭优化选项重新编译运行,如果此时没有异常发生,那么是gcc的优化有问题,否则是你的程序的问题。
如果是编译时的错误(应该不会是错误)或警告,那么先不要理它,运行了再说,如果运行没问题,那么最好修改你的程序结构,把这个警告消除掉。
是否给i赋值确实对生成代码有很大影响,有了常数,就可以做常量传播,有可能对程序结构带来很大的变化。