Re: make COMPAT_LINUX match SYSV binaries
On Wed, Oct 21, 2020 at 04:02:41PM +, Eduardo Horvath wrote: > On Wed, 21 Oct 2020, co...@sdf.org wrote: > > > In the event someone adds support for another OS with this problem (say, > > modern Solaris), I don't expect this compat to be enabled by default, > > for security reasons. So the problem will only occur if a user enables > > both forms of compat at the same time. > > But Solaris *IS* SYSV. > > Eduardo Solaris has a separate tag, but I'm not sure how consistently it's used. The SmartOS binaries do say: bin/dmenu: ELF 64-bit LSB executable, x86-64, version 1 (Solaris), dynamically linked, interpreter /usr/lib/amd64/ld.so.1, not stripped Bug Go-generated binaries say: main: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/amd64/ld.so.1, Go BuildID=OGLnPmMB8X-FwRbuu90n/GZ0Uvc8LQrh2V9P9rvDk/mRaPYobahbBw4F7aYitg/K58SIG6bmmaibHLZehP8, not stripped
Re: futexes
> On Oct 21, 2020, at 11:21 AM, m...@netbsd.org wrote: > > On Wed, Oct 21, 2020 at 05:49:38PM +0100, Robert Swindells wrote: >> >> Is there any way we can make progress with getting futexes to work >> properly ? >> >> At least post the latest non-working source somewhere so that people can >> try debugging it. >> > > I am under the impression they are committed. There is a bug tracked by an ATF test. I have a fix for that, but it introduces regressions. Robert, I know you want to help on this, but I have to update an OLD tree and get it working again before I'm ready to hand it off. I have not had a sufficient block of uninterrupted time to be able to do that yet. -- thorpej
Re: futexes
On Wed, Oct 21, 2020 at 05:49:38PM +0100, Robert Swindells wrote: > > Is there any way we can make progress with getting futexes to work > properly ? > > At least post the latest non-working source somewhere so that people can > try debugging it. > I am under the impression they are committed.
Re: futexes
Is there any way we can make progress with getting futexes to work properly ? At least post the latest non-working source somewhere so that people can try debugging it. Robert Swindells
Re: make COMPAT_LINUX match SYSV binaries
On Tue, Oct 20, 2020 at 07:11:05PM +, co...@sdf.org wrote: > hello, > > As a background, some Linux binaries don't claim to be targeting the > Linux OS, but instead are "SYSV". > > We have used some heuristics to still identify those binaries as being > Linux binaries, like looking into the symbols defined by the binary. > > it looks like we no longer have other forms of compat expected to use > SYSV ELF binaries. Perhaps we should drop this elaborate detection logic > in favour of detecting SYSV == Linux? > > As an added bonus, it allows detecting binaries built with a musl > toolchain as being Linux binaries. > I feel compelled to explain further: any OS that doesn't rely on this tag is prone to spitting out binaries with the wrong tag. For example, Go spits out Solaris binaries with SYSV as well. Our current solution to it is the kernel reading through the binary, checking if it contains certain known symbols that are common on Linux. We support the following forms of compat: ultrix not ELF sunos not ELF (we support only oold stuff) freebsd always correctly tagged, because the native OS checks this, like we do. linux ELF, not always correctly tagged So, currently, we only support one OS that has this problem, which is linux. I am proposing we take advantage of it. In the event someone adds support for another OS with this problem (say, modern Solaris), I don't expect this compat to be enabled by default, for security reasons. So the problem will only occur if a user enables both forms of compat at the same time. Users already have to opt in to have Linux compat support. I think it is a lot to ask to have them tag every binary.
Re: make COMPAT_LINUX match SYSV binaries
On Wed, 21 Oct 2020, co...@sdf.org wrote: > In the event someone adds support for another OS with this problem (say, > modern Solaris), I don't expect this compat to be enabled by default, > for security reasons. So the problem will only occur if a user enables > both forms of compat at the same time. But Solaris *IS* SYSV. Eduardo
Re: make COMPAT_LINUX match SYSV binaries
co...@sdf.org writes: > I feel compelled to explain further: > any OS that doesn't rely on this tag is prone to spitting out binaries > with the wrong tag. For example, Go spits out Solaris binaries with SYSV > as well. > > Our current solution to it is the kernel reading through the binary, > checking if it contains certain known symbols that are common on Linux. > > We support the following forms of compat: > > ultrixnot ELF > sunos not ELF (we support only oold stuff) > freebsd always correctly tagged, because the native OS > checks this, like we do. > linux ELF, not always correctly tagged > > > So, currently, we only support one OS that has this problem, which is > linux. I am proposing we take advantage of it. > > In the event someone adds support for another OS with this problem (say, > modern Solaris), I don't expect this compat to be enabled by default, > for security reasons. So the problem will only occur if a user enables > both forms of compat at the same time. > > Users already have to opt in to have Linux compat support. I think it is > a lot to ask to have them tag every binary. Thanks for the explanation. I'm still not thrilled, but I withdraw my objection. signature.asc Description: PGP signature
Re: make COMPAT_LINUX match SYSV binaries
On 21.10.2020 14:14, co...@sdf.org wrote: > On Tue, Oct 20, 2020 at 07:11:05PM +, co...@sdf.org wrote: >> hello, >> >> As a background, some Linux binaries don't claim to be targeting the >> Linux OS, but instead are "SYSV". >> >> We have used some heuristics to still identify those binaries as being >> Linux binaries, like looking into the symbols defined by the binary. >> >> it looks like we no longer have other forms of compat expected to use >> SYSV ELF binaries. Perhaps we should drop this elaborate detection logic >> in favour of detecting SYSV == Linux? >> >> As an added bonus, it allows detecting binaries built with a musl >> toolchain as being Linux binaries. >> > > I feel compelled to explain further: > any OS that doesn't rely on this tag is prone to spitting out binaries > with the wrong tag. For example, Go spits out Solaris binaries with SYSV > as well. > > Our current solution to it is the kernel reading through the binary, > checking if it contains certain known symbols that are common on Linux. > > We support the following forms of compat: > > ultrixnot ELF > sunos not ELF (we support only oold stuff) > freebsd always correctly tagged, because the native OS > checks this, like we do. > linux ELF, not always correctly tagged > > > So, currently, we only support one OS that has this problem, which is > linux. I am proposing we take advantage of it. > > In the event someone adds support for another OS with this problem (say, > modern Solaris), I don't expect this compat to be enabled by default, > for security reasons. So the problem will only occur if a user enables > both forms of compat at the same time. > > Users already have to opt in to have Linux compat support. I think it is > a lot to ask to have them tag every binary. > I couldn't run musl binaries without either patching the kernel or ELF files, so I'm for making this easier. In my case, I had to add manually build-id tag to musl binaries. For some reason someone in the kernel assumed that they are always present, which is just a special case in some distros. signature.asc Description: OpenPGP digital signature