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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux