Josh Elsasser <j...@elsasser.org> wrote:
> On Fri, Nov 29, 2019 at 10:12:10AM +0100, Thomas de Grivel wrote:
> > Maybe Go is not the only problem, I see SBCL compiling syscalls too.
> >
> > Truth is libc is for C and not all programs are written in C nowadays.
>
> Where are you seeing SBCL compiling direct syscalls? In my testing,
> SBCL self-hosts just fine under a kernel modified to disallow syscalls
> from the text segment, whereas go is killed under such a kernel. Are
> you sure you're not seeing SBCL compile calls to the libc syscall
> wrappers?
At this point, I am only aware of go. go can be fixed, actually go has
been fixed to satisfy ABI-instability on another system, and we here at
OpenBSD are the kings of ABI-instability and I have wanted us to go that
way, and I predict it will happen.
If other things are broken, we need accurate reports instead of drama.
The commited diff allows main-program-syscall in dynamic binaries until
go is fixed.
Here's a kernel diff which will expose such problems, by removing that
permission.
If other problems are identified, work on them can start in parallel.
Index: exec_elf.c
===================================================================
RCS file: /cvs/src/sys/kern/exec_elf.c,v
retrieving revision 1.152
diff -u -p -u -r1.152 exec_elf.c
--- exec_elf.c 29 Nov 2019 06:34:45 -0000 1.152
+++ exec_elf.c 29 Nov 2019 17:07:34 -0000
@@ -621,17 +621,12 @@ exec_elf_makecmds(struct proc *p, struct
}
} else
addr = ELF_NO_ADDR;
- /*
- * static binary: main program does system calls
- * dynamic binary: regular main program won't do system
- * calls, unfortunately go binaries do...
- */
- flags |= VMCMD_SYSCALL;
if (interp == NULL) {
/*
* static binary: no ld.so, no late request for
* syscalls inside libc,so block msyscall()
*/
+ flags |= VMCMD_SYSCALL;
p->p_vmspace->vm_map.flags |=
VM_MAP_SYSCALL_ONCE;
}
