Re: Removing syscall(2) from libc and kernel

2023-10-29 Thread Theo de Raadt
Here's the newest version of all 3 diffs: - kernel diff, can be tested alone - userland diff, can be tested alone - syscalls.master cleanup, would happen afterwards, and conflicts a bit. the ports team has repaired a majority of the syscall fallout in non-go programs. The effort for go is still

Re: Removing syscall(2) from libc and kernel

2023-10-27 Thread Lucas Gabriel Vuotto
On Fri, Oct 27, 2023 at 09:36:25AM -0600, Theo de Raadt wrote: > Index: sys/arch/m88k/m88k/trap.c > === > RCS file: /cvs/src/sys/arch/m88k/m88k/trap.c,v > diff -u -p -u -r1.128 trap.c > --- sys/arch/m88k/m88k/trap.c 2 Aug 2023 06:14:46

Re: Removing syscall(2) from libc and kernel

2023-10-27 Thread Theo de Raadt
Theo de Raadt wrote: > Piece by piece, I've been trying to remove the easiest of the > terminal-actions that exploit code uses (ie. getting to execve, or performing > other system calls, etc). > Snapshots for some architectures now contain kernel diffs which reject > syscall(2). The symbol still

Re: Removing syscall(2) from libc and kernel

2023-10-27 Thread Theo de Raadt
Theo de Raadt wrote: > Piece by piece, I've been trying to remove the easiest of the > terminal-actions that exploit code uses (ie. getting to execve, or performing > other system calls, etc). > So in this next step, I'm going to take away the ability to perform syscall #0 > (SYS_syscall), with t

Removing syscall(2) from libc and kernel

2023-10-27 Thread Theo de Raadt
Piece by piece, I've been trying to remove the easiest of the terminal-actions that exploit code uses (ie. getting to execve, or performing other system calls, etc). I recognize we can never completely remove all mechanisms they use. However, I hope I am forcing attack coders into using increasing