Re: [PATCH v2 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_sem properly in there

[Greg Ungerer]

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@xxxxxxxxxxxxxxx> 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