public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Kees Cook <keescook@chromium.org>, Jiri Kosina <jkosina@suse.cz>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Oleg Nesterov <oleg@redhat.com>, Ingo Molnar <mingo@redhat.com>,
	Baoquan He <bhe@redhat.com>, Michal Hocko <mhocko@suse.com>
Subject: [PATCH 2/2] fs, elf: drop MAP_FIXED from initial ET_DYN segment
Date: Mon, 16 Oct 2017 15:44:46 +0200	[thread overview]
Message-ID: <20171016134446.19910-3-mhocko@kernel.org> (raw)
In-Reply-To: <20171016134446.19910-1-mhocko@kernel.org>

From: Michal Hocko <mhocko@suse.com>

eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE") has added
MAP_FIXED flag to the initial ET_DYN segment mapping which defines the
randomized base for the PIE ELF segments. The thing is that MAP_FIXED
shouldn't be really needed because the address is essentially random
anyway. All other segments are mapped relatively to this base. elf_map
makes sure that all segments will fit into the address space by
enforcing total_mapping_size initial map.

Why do we want to drop MAP_FIXED in the first place? Because it is error
prone. If we happen to have an existing mapping in the requested range
then we do not want to corrupt it silently. Without MAP_FIXED vm_mmap
will simply fallback to another range. In reality there shouldn't be
any conflicting mappings at this early exec stage so the mmap should
succeed even without MAP_FIXED but subtle changes to the randomization
can break this assumption so we should rather be careful here.

Fixes: eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE")
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
 fs/binfmt_elf.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 09456e2add18..244cc30dfa24 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -988,7 +988,6 @@ static int load_elf_binary(struct linux_binprm *bprm)
 				load_bias = ELF_ET_DYN_BASE;
 				if (current->flags & PF_RANDOMIZE)
 					load_bias += arch_mmap_rnd();
-				elf_flags |= MAP_FIXED;
 			} else
 				load_bias = 0;
 
-- 
2.14.2

  parent reply	other threads:[~2017-10-16 13:45 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-04  7:50 MAP_FIXED for ELF mappings Michal Hocko
2017-10-04  7:59 ` Michal Hocko
2017-10-04 15:03 ` Baoquan He
2017-10-04 15:11   ` Michal Hocko
2017-10-04 15:12   ` Baoquan He
2017-10-04 15:17     ` Michal Hocko
2017-10-04 15:37       ` Baoquan He
2017-10-04 17:12         ` Michal Hocko
2017-10-04 17:15           ` Linus Torvalds
2017-10-04 17:28             ` Michal Hocko
2017-10-05 16:33       ` Oleg Nesterov
2017-10-05 16:42         ` Michal Hocko
2017-10-16 13:44 ` [PATCH 0/2] fs, elf: get rid of MAP_FIXED from the loader Michal Hocko
2017-10-16 13:44   ` [PATCH 1/2] fs, elf: drop MAP_FIXED usage from elf_map Michal Hocko
2017-10-16 16:39     ` Kees Cook
2017-10-16 19:00       ` Michal Hocko
2017-10-16 20:02         ` James Hogan
2017-10-17  7:37           ` Michal Hocko
2017-10-17  8:35             ` James Hogan
2017-10-17  8:56               ` Michal Hocko
2017-10-17 12:26     ` Baoquan He
2017-10-17 12:56       ` Michal Hocko
2017-10-17 13:22         ` Baoquan He
2017-10-17 13:33           ` Michal Hocko
2017-10-17 13:42             ` Baoquan He
2017-10-16 13:44   ` Michal Hocko [this message]
2017-10-16 16:44     ` [PATCH 2/2] fs, elf: drop MAP_FIXED from initial ET_DYN segment Kees Cook
2017-10-16 18:43       ` Michal Hocko
2017-10-16 19:38         ` Kees Cook
2017-10-17  9:04           ` Michal Hocko
2017-10-17 20:01             ` Kees Cook
2017-10-19 11:20               ` Michal Hocko
2017-10-19 17:19                 ` Kees Cook
2017-10-20  8:45                   ` Michal Hocko
2017-10-20 14:12                     ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171016134446.19910-3-mhocko@kernel.org \
    --to=mhocko@kernel.org \
    --cc=bhe@redhat.com \
    --cc=jkosina@suse.cz \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox