lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 1 May 2020 16:00:28 +1000 From: Greg Ungerer <gerg@...ux-m68k.org> To: Rich Felker <dalias@...c.org> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Russell King - ARM Linux admin <linux@...linux.org.uk>, Jann Horn <jannh@...gle.com>, Nicolas Pitre <nico@...xnic.net>, Andrew Morton <akpm@...ux-foundation.org>, Christoph Hellwig <hch@....de>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Linux-MM <linux-mm@...ck.org>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, Alexander Viro <viro@...iv.linux.org.uk>, "Eric W . Biederman" <ebiederm@...ssion.com>, Oleg Nesterov <oleg@...hat.com>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, Mark Salter <msalter@...hat.com>, Aurelien Jacquiot <jacquiot.aurelien@...il.com>, linux-c6x-dev@...ux-c6x.org, Yoshinori Sato <ysato@...rs.sourceforge.jp>, Linux-sh list <linux-sh@...r.kernel.org> Subject: Re: [PATCH v2 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_sem properly in there On 1/5/20 12:51 am, Rich Felker wrote: > On Fri, May 01, 2020 at 12:10:05AM +1000, Greg Ungerer wrote: >> >> >> On 30/4/20 9:03 am, Linus Torvalds wrote: >>> On Wed, Apr 29, 2020 at 2:57 PM Russell King - ARM Linux admin >>> <linux@...linux.org.uk> wrote: >>>> >>>> I've never had any reason to use FDPIC, and I don't have any binaries >>>> that would use it. Nicolas Pitre added ARM support, so I guess he >>>> would be the one to talk to about it. (Added Nicolas.) >>> >>> While we're at it, is there anybody who knows binfmt_flat? >>> >>> It might be Nicolas too. >>> >>> binfmt_flat doesn't do core-dumping, but it has some other oddities. >>> In particular, I'd like to bring sanity to the installation of the new >>> creds, and all the _normal_ binfmt cases do it largely close together >>> with setup_new_exec(). >>> >>> binfmt_flat is doing odd things. It's doing this: >>> >>> /* Flush all traces of the currently running executable */ >>> if (id == 0) { >>> ret = flush_old_exec(bprm); >>> if (ret) >>> goto err; >>> >>> /* OK, This is the point of no return */ >>> set_personality(PER_LINUX_32BIT); >>> setup_new_exec(bprm); >>> } >>> >>> in load_flat_file() - which is also used to loading _libraries_. Where >>> it makes no sense at all. >> >> I haven't looked at the shared lib support in there for a long time, >> but I thought that "id" is only 0 for the actual final program. >> Libraries have a slot or id number associated with them. > > This sounds correct. My understanding of FLAT shared library support > is that it's really bad and based on having preassigned slot indices > for each library on the system, and a global array per-process to give > to data base address for each library. Libraries are compiled to know > their own slot numbers so that they just load from fixed_reg[slot_id] > to get what's effectively their GOT pointer. > > I'm not sure if anybody has actually used this in over a decade. Last > time I looked the tooling appeared broken, but in this domain lots of > users have forked private tooling that's not publicly available or at > least not publicly indexed, so it's hard to say for sure. Be at least 12 or 13 years since I last had a working shared library build for m68knommu. I have not bothered with it since then, not that I even used it much when it worked. Seemed more pain than it was worth. Regards Greg
Powered by blists - more mailing lists