Date: Sat, 31 Oct 2020 10:48:18 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: [PATCH v2] MT fork On Sat, Oct 31, 2020 at 03:35:57PM +0200, Timo Teras wrote: > On Sat, 31 Oct 2020 14:29:32 +0100 > Szabolcs Nagy <nsz@...t70.net> wrote: > > > * Timo Teras <timo.teras@....fi> [2020-10-31 09:22:04 +0200]: > > > > > On Fri, 30 Oct 2020 15:31:54 -0600 > > > Ariadne Conill <ariadne@...eferenced.org> wrote: > > > > > > > I have pushed current musl git plus the MT fork patch to Alpine > > > > edge as Alpine musl 1.2.2_pre0, and reenabling parallel mark has > > > > worked fine. > > > > > > > > It would be nice to have a musl 1.2.2 release that I can use for > > > > the source tarball instead of a git snapshot, but this will do > > > > for now. > > > > > > And now firefox is utterly broken. Though seems to be not related > > > to MT fork patch. > > > > > > Bisected it down to commit b8b729bd22c28c9116c2fce65dce207a35299c26 > > > "fix missing O_LARGEFILE values on x86_64, x32, and mips64" > > > > > > I think this breaks the seccomp because now e.g. fopen() calls has > > > this bit set for the syscall and seccomp does not like it. > > > > > > Wondering whether to fix firefox seccomp ignore this bit, or if this > > > commit needs reconsideration? > > > > please report it to firefox while we work out what's best. > > > > this is something they sould be aware of. > > Turns out the rebuilding firefox was enough. They allow O_LARGEFILE > there, but when built with earlier musl version it was zero... > > So basically the change there requires rebuild of certain applications. > Even if from kernel side the bit makes no big difference, but from > seccomp side it does. It does make a difference from the kernel side. If a file is opened without it, passing the fd to 32-bit processes is unsafe. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.