Re: syscall call-from verification

2019-12-02 Thread Thomas de Grivel
My bad, SBCL uses the libc's wrappers indeed looking at the sources. Le ven. 29 nov. 2019 à 22:41, Josh Elsasser a écrit : > > 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

Re: syscall call-from verification

2019-11-30 Thread Pavel Korovin
I missed the point, sorry. What I mean that without the patch, lang/go and go ports are fine on -current. On 11/30, Christian Weisgerber wrote: > Pavel Korovin: > > > In my partial dpb build, lang/go goes fine. > > My amd64 snapshot was custom-built from sources, dated 2019-11-30 ~02 a.m. > >

Re: syscall call-from verification

2019-11-30 Thread Christian Weisgerber
Pavel Korovin: > In my partial dpb build, lang/go goes fine. > My amd64 snapshot was custom-built from sources, dated 2019-11-30 ~02 a.m. ... and obviously without Theo's patch to sys/kern/exec_elf.c from earlier in this thread. -- Christian "naddy" Weisgerber

Re: syscall call-from verification

2019-11-30 Thread Pavel Korovin
In my partial dpb build, lang/go goes fine. My amd64 snapshot was custom-built from sources, dated 2019-11-30 ~02 a.m. go ports (net/mattermos-server, sysutils/beats/filebeat, www/gitea) are functional. On 11/30, Christian Weisgerber wrote: > > I'm running an amd64 bulk build with this. > > The

Re: syscall call-from verification

2019-11-30 Thread Christian Weisgerber
On 2019-11-30, Christian Weisgerber wrote: >> 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 >>

Re: syscall call-from verification

2019-11-30 Thread Christian Weisgerber
On 2019-11-29, "Theo de Raadt" wrote: > 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. I'm

Re: syscall call-from verification

2019-11-29 Thread Theo de Raadt
Josh Elsasser 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

Re: syscall call-from verification

2019-11-29 Thread Josh Elsasser
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

Re: syscall call-from verification

2019-11-29 Thread Thomas de Grivel
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. Le jeu. 28 nov. 2019 à 21:04, Theo de Raadt a écrit : > > Miod Vallat wrote: > > > > For dynamic binaries, valid regions are ld.so's text segment, the

Re: syscall call-from verification

2019-11-28 Thread Theo de Raadt
Miod Vallat wrote: > > For dynamic binaries, valid regions are ld.so's text segment, the signal > > trampoline, and libc.so's text segment... AND the main program's text. > > > > Unfortunately our current go build model hasn't followed solaris/macos > > approach yet of calling libc stubs, and

Re: syscall call-from verification

2019-11-28 Thread Miod Vallat
> For dynamic binaries, valid regions are ld.so's text segment, the signal > trampoline, and libc.so's text segment... AND the main program's text. > > Unfortunately our current go build model hasn't followed solaris/macos > approach yet of calling libc stubs, and uses the inappropriate "embed >

Re: syscall call-from verification

2019-11-28 Thread Theo de Raadt
Alexander Nasonov wrote: > Theo de Raadt wrote: > > The following change only permits system calls from address-ranges > > in the process which system calls are expected from. > > Just curious if some approximation of pledge can be reimplemented > in userspace with more granular libc.so's text

Re: syscall call-from verification

2019-11-28 Thread Alexander Nasonov
Theo de Raadt wrote: > The following change only permits system calls from address-ranges > in the process which system calls are expected from. Just curious if some approximation of pledge can be reimplemented in userspace with more granular libc.so's text segments? -- Alex

Re: syscall call-from verification

2019-11-27 Thread Steffen Nurpmeso
Theo de Raadt wrote in <91679.1574892...@cvs.openbsd.org>: |Steffen Nurpmeso wrote: |1> Theo de Raadt wrote in <29275.1574888...@cvs.openbsd.org>: |>|The following change only permits system calls from address-ranges |>|in the process which system calls are expected from. |> ...

Re: syscall call-from verification

2019-11-27 Thread Theo de Raadt
Steffen Nurpmeso wrote: 1> Theo de Raadt wrote in <29275.1574888...@cvs.openbsd.org>: > |The following change only permits system calls from address-ranges > |in the process which system calls are expected from. > ... > |Unfortunately our current go build model hasn't followed solaris/macos

Re: syscall call-from verification

2019-11-27 Thread Steffen Nurpmeso
Theo de Raadt wrote in <29275.1574888...@cvs.openbsd.org>: |The following change only permits system calls from address-ranges |in the process which system calls are expected from. ... |Unfortunately our current go build model hasn't followed solaris/macos |approach yet of calling libc

syscall call-from verification

2019-11-27 Thread Theo de Raadt
The following change only permits system calls from address-ranges in the process which system calls are expected from. If you manage to upload exploit code containing a raw system call sequence and instruction, and mprotect -w+x that block, such a system call will not succeed but the process is