Add signal functionalities

[Mivik]

Description

Depends on oscomp/arceos#34

This PR implements signal functionalities, including:

• Various syscalls (See src/syscall.rs)
• Sending signal on process exit (eixt_signal)
• A test covering the majority of signal syscalls
• Enhancement on current clone implementation

[lurenjia1213]

Because all trampolines in user mode programs are located at the same physical address, if I understand correctly, I can add write permissions through mprotect and replace this part of the code with malicious shellcode. When other programs sigreturn, the control flow will be hijacked

Other kernel code is not in the va_range of the user mode program address space, so it avoids being modified

[Azure-stars]

Because all trampolines in user mode programs are located at the same physical address, if I understand correctly, I can add write permissions through mprotect and replace this part of the code with malicious shellcode. When other programs sigreturn, the control flow will be hijacked

Other kernel code is not in the va_range of the user mode program address space, so it avoids being modified

You are right. But see doc about sigreturn:

Once upon a time, UNIX systems placed the signal trampoline code onto the user stack. Nowadays, pages of the user stack are protected so as to disallow code execution. Thus, on contemporary Linux systems, depending on the architecture, the signal trampoline code lives either in the vdso(7) or in the C library.
In the latter case, the C library's sigaction(2) wrapper function informs the kernel of the location of the trampoline code by placing its address in the sa_restorer field of the sigaction structure, and sets the SA_RESTORER flag in the sa_flags field.

The assembly code of sigreturn should be implemented in the VDSO, which is not yet implemented in Starry. Therefore, we temporarily use the old Linux implementation, although it has certain security issues.

If you are interested in VDSO, you can contact me.

[lurenjia1213]

Because all trampolines in user mode programs are located at the same physical address, if I understand correctly, I can add write permissions through mprotect and replace this part of the code with malicious shellcode. When other programs sigreturn, the control flow will be hijacked
Other kernel code is not in the va_range of the user mode program address space, so it avoids being modified

You are right. But see doc about sigreturn:

Once upon a time, UNIX systems placed the signal trampoline code onto the user stack. Nowadays, pages of the user stack are protected so as to disallow code execution. Thus, on contemporary Linux systems, depending on the architecture, the signal trampoline code lives either in the vdso(7) or in the C library.
In the latter case, the C library's sigaction(2) wrapper function informs the kernel of the location of the trampoline code by placing its address in the sa_restorer field of the sigaction structure, and sets the SA_RESTORER flag in the sa_flags field.

The assembly code of sigreturn should be implemented in the VDSO, which is not yet implemented in Starry. Therefore, we temporarily use the old Linux implementation, although it has certain security issues.

If you are interested in VDSO, you can contact me.

Maybe we will try to implement VSDO in the final.
We are currently preparing for the final exam

[Azure-stars]

Because all trampolines in user mode programs are located at the same physical address, if I understand correctly, I can add write permissions through mprotect and replace this part of the code with malicious shellcode. When other programs sigreturn, the control flow will be hijacked
Other kernel code is not in the va_range of the user mode program address space, so it avoids being modified

You are right. But see doc about sigreturn:

Once upon a time, UNIX systems placed the signal trampoline code onto the user stack. Nowadays, pages of the user stack are protected so as to disallow code execution. Thus, on contemporary Linux systems, depending on the architecture, the signal trampoline code lives either in the vdso(7) or in the C library.
In the latter case, the C library's sigaction(2) wrapper function informs the kernel of the location of the trampoline code by placing its address in the sa_restorer field of the sigaction structure, and sets the SA_RESTORER flag in the sa_flags field.

The assembly code of sigreturn should be implemented in the VDSO, which is not yet implemented in Starry. Therefore, we temporarily use the old Linux implementation, although it has certain security issues.
If you are interested in VDSO, you can contact me.

Maybe we will try to implement VSDO in the final. We are currently preparing for the final exam

OK.Good luck on your exam!