• R/O
  • HTTP
  • SSH

tomoyo-test1: コミット

This is a test repository.


リビジョンb212921b13bda088a004328457c5c21458262fe2 (tree)
日時2019-10-07 05:53:27
作者Linus Torvalds <torvalds@linu...>
コミッターLinus Torvalds


elf: don't use MAP_FIXED_NOREPLACE for elf executable mappings

In commit 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map") we
changed elf to use MAP_FIXED_NOREPLACE instead of MAP_FIXED for the
executable mappings.

Then, people reported that it broke some binaries that had overlapping
segments from the same file, and commit ad55eac74f20 ("elf: enforce
MAP_FIXED on overlaying elf segments") re-instated MAP_FIXED for some
overlaying elf segment cases. But only some - despite the summary line
of that commit, it only did it when it also does a temporary brk vma for
one obvious overlapping case.

Now Russell King reports another overlapping case with old 32-bit x86
binaries, which doesn't trigger that limited case. End result: we had
better just drop MAP_FIXED_NOREPLACE entirely, and go back to MAP_FIXED.

Yes, it's a sign of old binaries generated with old tool-chains, but we
do pride ourselves on not breaking existing setups.

This still leaves MAP_FIXED_NOREPLACE in place for the load_elf_interp()
and the old load_elf_library() use-cases, because nobody has reported
breakage for those. Yet.

Note that in all the cases seen so far, the overlapping elf sections
seem to be just re-mapping of the same executable with different section
attributes. We could possibly introduce a new MAP_FIXED_NOFILECHANGE
flag or similar, which acts like NOREPLACE, but allows just remapping
the same executable file using different protection flags.

It's not clear that would make a huge difference to anything, but if
people really hate that "elf remaps over previous maps" behavior, maybe
at least a more limited form of remapping would alleviate some concerns.

Alternatively, we should take a look at our elf_map() logic to see if we
end up not mapping things properly the first time.

In the meantime, this is the minimal "don't do that then" patch while
people hopefully think about it more.

Reported-by: Russell King <linux@armlinux.org.uk>
Fixes: 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map")
Fixes: ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments")
Cc: Michal Hocko <mhocko@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>



--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -879,7 +879,7 @@ out_free_interp:
879879 the correct location in memory. */
880880 for(i = 0, elf_ppnt = elf_phdata;
881881 i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {
882- int elf_prot, elf_flags, elf_fixed = MAP_FIXED_NOREPLACE;
882+ int elf_prot, elf_flags;
883883 unsigned long k, vaddr;
884884 unsigned long total_size = 0;
@@ -911,13 +911,6 @@ out_free_interp:
911911 */
912912 }
913913 }
915- /*
916- * Some binaries have overlapping elf segments and then
917- * we have to forcefully map over an existing mapping
918- * e.g. over this newly established brk mapping.
919- */
920- elf_fixed = MAP_FIXED;
921914 }
923916 elf_prot = make_prot(elf_ppnt->p_flags);
@@ -930,7 +923,7 @@ out_free_interp:
930923 * the ET_DYN load_addr calculations, proceed normally.
931924 */
932925 if (loc->elf_ex.e_type == ET_EXEC || load_addr_set) {
933- elf_flags |= elf_fixed;
926+ elf_flags |= MAP_FIXED;
934927 } else if (loc->elf_ex.e_type == ET_DYN) {
935928 /*
936929 * This logic is run once for the first LOAD Program
@@ -966,7 +959,7 @@ out_free_interp:
966959 load_bias = ELF_ET_DYN_BASE;
967960 if (current->flags & PF_RANDOMIZE)
968961 load_bias += arch_mmap_rnd();
969- elf_flags |= elf_fixed;
962+ elf_flags |= MAP_FIXED;
970963 } else
971964 load_bias = 0;