fe4082ca9e
!709 A核代码静态告警定期清理
...
Merge pull request !709 from wangchen/1112_codex
2021-11-16 06:47:22 +00:00
9ba725c3d4
fix: A核代码静态告警定期清理
...
【背景】A核代码静态告警定期清理
【修改方案】
1，根据codex等工具分析结果，进行必要的规范等问题修改
【影响】
对现有的产品编译不会有影响。
re #I4I0O8
Signed-off-by: wangchen <253227059@qq.com>
2021-11-15 02:47:08 +00:00
0f878febb7
chore: 修复社区反馈问题Percpu结构体注释错误
...
修复社区反馈问题Percpu结构体注释错误，排查下其他拼写错误。
close #I4GMLH
Signed-off-by: kenneth <zhushangyuan@huawei.com>
2021-11-10 10:20:33 +08:00
bda00e6747
!655 TCB中使用的execFile字段改为execVnode
...
Merge pull request !655 from LeonChan/execfile
2021-10-15 01:45:58 +00:00
665c152c27
fix: 修复硬随机不可用时，地址随机化不可用问题
...
方案：硬随机不可用时，默认使用软随机数代替硬随机数
close #I4D4TK
Signed-off-by: Haryslee <lihao189@huawei.com>
Change-Id: Ia7d2a9583257d7b8041b8994a70a7c36149c33fb
2021-10-11 10:00:08 +08:00
e4a06623ce
fix: change the execFile field in TCB to execVnode
...
TEE需要借用TCB中的execFile来校验打开的文件，pagecache修改后，可执行程序在mmap之后，会被立即关闭，因此将execFile改为execVnode
close: #I4CLL9
Signed-off-by: Leon Chan <chenwei26@huawei.com>
2021-09-30 14:33:36 +08:00
06ea03715f
feat: 支持AT_RANDOM以增强用户态栈保护能力
...
背景：不开地址随机化时，用户态栈CANARY值是固定值
方案：支持AT_RANDOM，CANARY从AT_RANDOM获取随机值以增强用户态栈保护能力
close #I4CB8M
Signed-off-by: Haryslee <lihao189@huawei.com>
Change-Id: I28cef09f7016a5096e2096d4f6aa72722fcf1fd7
2021-09-30 10:36:12 +08:00
7d7cff4c51
!633 fix: codex清理
...
Merge pull request !633 from Far/master
2021-09-27 08:38:37 +00:00
9ab3e351d3
fix: codex 清理
...
Close #I4BL3S
Signed-off-by: Far <yesiyuan2@huawei.com>
2021-09-27 14:43:28 +08:00
a375bf5668
fix: close file when process interpretor failed
...
close: #I4ATQX
Signed-off-by: Leon Chan <chenwei26@huawei.com>
2021-09-18 15:02:22 +08:00
ecd9ca7781
!534 pagecache从filep改为使用vnode
...
Merge pull request !534 from LeonChan/pg
2021-09-15 03:51:50 +00:00
38a6b804e9
feat: page cache backed by vnode instead of filep
...
1, change the owner of page to vnode
2, save the file path in vnode
close: #I44TBS
Signed-off-by: Leon Chan <chenwei26@huawei.com>
2021-09-14 15:31:33 +08:00
b3d96d166c
refactor: 清理Makefile冗余项
...
清理Makefile冗余项，各模块Makefile里不需要再次引用公共路径，只需引用私有头文件路径
close: #I49MOO
Signed-off-by: arvinzzz <zhaotianyu9@huawei.com>
Change-Id: I2dd7189c866498896461f78bfed5444ae1d86876
2021-09-13 18:14:15 +08:00
ba977dd5ab
!605 refactor: 内核目录结构整理
...
Merge pull request !605 from Zhaotianyu/0902dir_refactor
2021-09-09 01:23:33 +00:00
33d0c1bd0b
refactor: 内核目录结构整理
...
1. 原kernel/common目录下属于内核拓展组件，统一移入kernel/extend管理
2. Kconfig分层，各模块自己的配置放到自己目录下管理
3. 原platform下不属于平台的公共代码抽到kernel/common下，只留板级链接脚本和一些编译脚本指向device目录下触发平台相关的编译
4. 对外公共头文件统一抽到对外include路径
5. 废弃宏，头文件清理
close: #I48KI4
Signed-off-by: arvinzzz <zhaotianyu9@huawei.com>
Change-Id: I0cf5ea81c92a8fa7b113da9cbdc8b7bc935f5aae
2021-09-08 16:36:28 +08:00
597ced7948
!595 fix: dyload open close failed
...
Merge pull request !595 from MGY917/dyload_fd
2021-09-08 08:26:55 +00:00
5e87d8c183
fix: dyload open close failed
...
本次提交修复内核加载器，异常情况分支的一个bug：mksh通过exec命令（mksh内置命令
，正常情况下，该命令成功执行会复用mksh进程空间，拉起新的指定进程）。但是如果
进程没有成功加载的情况下，内核加载器的异常分支会错误释放mksh的fd句柄。最终导致
下次拉起其他进程时（fork + exec方式），新的进程会继承fd，映射了早就释放的sysfd
，此时的sysfd可能已经被复用，issue场景下这个sysfd被加载过程中打开的libc.so占用
，exec时会释放procfd->sysfd(错误的映射关系)，最终新进程libc.so被关闭。
导致内核崩溃。
close #I452Z7
Signed-off-by: Guangyao Ma <guangyao.ma@outlook.com>
Change-Id: Ifca809f88b5ffcfb879dc5520d1f6adf5cf92bcd
2021-09-07 16:28:37 +08:00
0f4d5a4b0c
!287 feat(vfs): vfs支持FD_CLOEXEC标记
...
Merge pull request !287 from MGY917/master
2021-08-12 00:36:19 +00:00
27dca4d857
feat(vfs): vfs支持FD_CLOEXEC标记
...
首先，POSIX规范规定文件描述符需要支持close-on-exec属性，修改前的vfs不支持close-on-exec，当exec系列函数执行时，进程所有的文件将会被关闭（0，1，2也重新被打开）。但是，系统有些时候是不能在exec时关闭全部文件的，例如在执行exec之前，就需要重定向进程的某些文件描述符时（使用dup2），就希望该文件不被关闭，继续保持重定向属性，shell执行进程并重定向其标准输出到文件，这是我们经常做的事情。
BREAKING CHANGE:
执行exec类函数后，进程拥有的文件描述符情况发生变化：修改前，默认关闭所有的进程文件描述符，0，1，2重新打开；修改后，除非文件描述符拥有FD_CLOEXEC标记，否则该描述符不会被关闭。
re #I3U81W
Change-Id: I54e841ac88e9835ec23e97de0cbc906c4e11f5a4
Signed-off-by: Guangyao Ma <guangyao.ma@outlook.com>
2021-08-11 15:35:46 +08:00
42f374dd7a
fix: 合并进程栈两个地址连续的region
...
背景：进程加载的时候，先预申请一个页用作参数拷贝，另外通过mmap方式申请
额外的虚拟栈空间，此时便有两个地址连续的区间。
方案：新增内部接口OsStackAlloc，用于申请一个连续的虚拟地址区间，并对其
中指定区间做物理内存的映射。
close #I43QYJ
Signed-off-by: Haryslee <lihao189@huawei.com>
Change-Id: I224cca3671c42a94c2f74b2da5a11403849e33d3
2021-08-10 17:20:17 +08:00
a8805a65aa
feat: add support for gn build system
...
add BUILD.gn for all kernel modules
Signed-off-by: Caoruihong <crh.cao@huawei.com>
Change-Id: I018446427bf64615f2596d47862b219659b58b34
2021-07-21 15:52:40 +08:00
9db3407589
feat: 基于汇编实现内核对用户态内存清零的功能
...
背景：LOS_UserMemClear接口原有实现是通过在内核中
申请一块堆内存并对其清零，调用copy_to_user来达到
对用户态内存清零的目的，需要使用堆内存。
修改方案：基于汇编实现内核对用户态内存清零的功能。
close #I3XXT0
Change-Id: I27cb1e45559cb75a9b330799fe427abd54f51c15
Signed-off-by: Haryslee <lihao189@huawei.com>
2021-06-26 15:31:42 +08:00
73a777777e
fix: remove redundant headfile
...
1.remove redundant headfile in kernel, such as:
compiler.h;debug.h;automount.h;inode.h;syslog.h;net.h;
2.split fs.h to file.h and driver.h
3.move vnode.h and path_cache.h to vfs/include
4.remove redundant interface and defines
close: #I3RTNR
Signed-off-by: mucor <mucorwang@gmail.com>
2021-06-19 17:32:47 +08:00
f0b419099d
chore: rename function OsCreateUserVmSpace
...
rename function OsCreateUserVmSpace to fix typo
close https://gitee.com/openharmony/kernel_liteos_a/issues/I3QD42
Signed-off-by: kenneth <459864689@qq.com>
2021-06-16 15:00:53 +08:00
8cde768588
refactor: Refactored the kernel boot process and added a init framework
...
close: #I3I768
Change-Id: I4f801df4abe1a9afdf43391c28276e96a5e81513
2021-05-20 16:45:43 +08:00
7e73c929a2
remove __cplusplus guards in .c files
...
Change-Id: I052d930d54e63179b17b77f02c107a015f3cfc3f
2021-04-19 18:28:25 +08:00
73a7b66116
update openharmony 1.0.1
2021-03-11 18:43:57 +08:00
63bd69267a
drop unnecessary executable file permission mode
...
Change-Id: Ia6c1f6302407a707b3ec9b805f4c92d8a7970b86
2020-10-13 16:37:25 +08:00
f62115dfef
Fix mmap
2020-09-28 16:32:18 +08:00
6df931fc98
add OpenHarmony 1.0 baseline
2020-09-08 17:22:24 +08:00
openharmony_ci
lnlan
kenneth
Haryslee
Leon Chan
Far
arvinzzz
Guangyao Ma
Caoruihong
mucor
kenneth
arvinzzz
mamingshuai
Harylee
wenjun