除了安全编译选项问题,
还有性能编译选项问题;
请build-SIG一起考虑下;
请openEuler编译默认ELF使用2M对齐
openEuler X86编译默认是4K对齐,
AMR64是64K对齐;
这两种对齐方式都会导致透明大页特性开启的时候,
无法有效使用透明大页;
因此需要将openEuler编译对齐为2M对齐;
From: Hexiaowen (Hex, EulerOS) [mailto:hexiaowen@huawei.com]
Sent: Tuesday, November 16, 2021 10:11 AM
To: Chenxi Mao <chenxi.mao@suse.com>; dev@openeuler.org
Subject: [Dev] 答复:
关于欧拉操作系统gcc_secure包问题的讨论
很感谢你的参与,我尝试答复下这个问题,有不合理的地方,希望可以一起改进:
我是SUSE的毛晨曦,目前正在从事基于欧拉的发行版的开发和调研工作。
在开发的过程当中,关于GCC_secure的相关问题,想请教一下社区的开发者和维护者。后续我想会在GCC_secure这个包上面做一些开发维护工作。
Ø
Gcc_secure这个软件产生的背景是,需要对所有gcc编译的软件添加安全编译选项,
Ø
最开始的方案是选择修改rpm CFLAGS等编译选项,但发现无法覆盖所有,特别是没有makefile,直接使用脚本或其他方式构建的软件。
Ø
Gcc_secure的方案很粗暴,但有效,也在尝试改进方案。
根据我对于GCC _secure包的理解,GCC_secure包主要完成了下面几项工作:
1. 在gcc_secure包中增加了部分安全相关的编译参数,如pic/pie/fsprotect等,目的是增强整个openEuler的安全性
2. 增加了fsigned-char参数,为了保证arm64和X86的平台可移植性。
3. 在gcc_secure中定义了一个exclude名单,这个名单是在project config中进行定义的,里面包含了大约几十个包
Ø
这里的描述准确,恰恰是gcc_secure的功能,
Ø
关于gcc_secure的实现,有一些不太了解的地方想请开发者、维护者帮我理清一下。
1.
gcc_exclude的这个名单,是否是因为一些已知问题,才将这些软件包放在exclude的名单中?后续时候会根据版本演进,逐渐将这些包也使用gcc_secure的方式进行编译,如果开发者或维护者已经有相关计划或规划,烦请分享一下相关计划,后续可以共同解决这个问题,使得编译一致化。
Ø
Exclude名单是在日常处理时,发现的不能使用gcc_secure,或只能使用某一个或几个安全编译选项,
这个早期的方案现在看来导致整个系统的构建极其混乱,需要整改。
2.
在gcc_secure中增加fsigned-char使得ARM64的行为与X86一致,是否可以从源代码的层面解决会更加彻底一些,最终将fsigned-char从gcc_secure中移除。这方面我已经做了一些初步的工作,已经提交到社区。如果获得批准,后续我也会继续完善这方面工作。
Ø
非常赞成你的观点,源码层面的问题,就应该由开发者在源码层面闭环掉,而不应该让整个编译系统兜底。
几个PR我会检视合入,
再次感谢你的热心。
发件人: Chenxi Mao [mailto:chenxi.mao@suse.com]
发送时间: 2021年11月15日
17:31
收件人:
dev@openeuler.org
抄送: Chenxi Mao <chenxi.mao@suse.com>
主题: [Dev] 关于欧拉操作系统gcc_secure包问题的讨论
Hi
各位尊敬的开发者和维护者:
您好,
我是SUSE的毛晨曦,目前正在从事基于欧拉的发行版的开发和调研工作。
在开发的过程当中,关于GCC_secure的相关问题,想请教一下社区的开发者和维护者。后续我想会在GCC_secure这个包上面做一些开发维护工作。
根据我对于GCC _secure包的理解,GCC_secure包主要完成了下面几项工作:
1. 在gcc_secure包中增加了部分安全相关的编译参数,如pic/pie/fsprotect等,目的是增强整个openEuler的安全性
2. 增加了fsigned-char参数,为了保证arm64和X86的平台可移植性。
3. 在gcc_secure中定义了一个exclude名单,这个名单是在project config中进行定义的,里面包含了大约几十个包
关于gcc_secure的实现,有一些不太了解的地方想请开发者、维护者帮我理清一下。
1. gcc_exclude的这个名单,是否是因为一些已知问题,才将这些软件包放在exclude的名单中?后续时候会根据版本演进,逐渐将这些包也使用gcc_secure的方式进行编译,如果开发者或维护者已经有相关计划或规划,烦请分享一下相关计划,后续可以共同解决这个问题,使得编译一致化。
2. 在gcc_secure中增加fsigned-char使得ARM64的行为与X86一致,是否可以从源代码的层面解决会更加彻底一些,最终将fsigned-char从gcc_secure中移除。这方面我已经做了一些初步的工作,已经提交到社区。如果获得批准,后续我也会继续完善这方面工作。
初步提交的PR如下:
烦请社区维护者审阅
相关问题在gitee上的地址:
Chenxi