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
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.
>
>
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
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
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
>>
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
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
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
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
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
> 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
>
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
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
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.
|> ...
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
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
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
17 matches
Mail list logo
