This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug dynamic-link/20480] Patch: ifunc not executable, crashes sudo qemu


https://sourceware.org/bugzilla/show_bug.cgi?id=20480

--- Comment #6 from Adam J. Richter <adam_richter2004 at yahoo dot com> ---
Regarding my version 2 patch, I want to mention that I can envision the
following refinements, although I recommend integrating it in the meantime.

a. To reduce the number of mprotect system calls made, remove the mprotect
calls that I changed and instead require callers of _dl_relocate_object already
to have all of the sections of the file being relocated mapped rwx (or, if that
fails, rw, for systems that prohibit wx).

b. Also to reduce the number of system calls, make part to reprotects memory
skip the mprotect calls when the permissions are already what we want (rwx or
rw, depending on whether rwx was allowed).

c. Finally, and this would be a big change, to make ifuncs work on
configurations that prohibit rwx memory, have a slower fallback that sets
skip_ifuncs upon detecting that rwx memory is prohibited, and then have another
pass of relocations after memory proections have been set to their final value
that takes the result returned by the ifunc call, temporarily sets just the
page(s) holding the ifunc target to writable, writes the ifunc result, and then
restores their protections.  Conceivably, this could be optimized by
remembering multiple ifunc results before writing them back to the same page. 
This would be a big, slow, complex rarely used corner case, and I certainly
would welcome alternative suggestions, but this is the only way that I have
thought of so far for systems that do not allow read+write+execute memory
mappings to support ifuncs (which I believe can be in any section, including
the section of the target relocation).

Also, I am convinced the problem is in glibc as I described.  If you still
think it could be in binutils, gcc, etc., I need you to describe a scenario,
given the current information, for how that could be, if you want me to look
into it.

Meanwhile, I will try to generate a smaller test case to reproduce the problem.

Thanks again for your response.  I completely agree that we should support
systems that prohibit rwx memory mappings, at the very least to the extent that
we do so now (that is, non-ifunc code works always, and ifunc works for a
kernel facility like READ_IMPLIES_EXEC).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]