All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Kees Cook <keescook@chromium.org>,
	Oleg Nesterov <oleg@redhat.com>, Jiri Kosina <jkosina@suse.cz>,
	Al Viro <viro@zeniv.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: MAP_FIXED for ELF mappings
Date: Wed, 4 Oct 2017 23:37:41 +0800	[thread overview]
Message-ID: <20171004153741.GH24886@x1> (raw)
In-Reply-To: <20171004151700.k4fvivvmi7pm5sl7@dhcp22.suse.cz>

On 10/04/17 at 05:17pm, Michal Hocko wrote:
> On Wed 04-10-17 23:12:38, Baoquan He wrote:
> > I made a clean up patch according to Oleg's suggestion. It's trying to
> > get an map area to cover total_size, then do mmap for for the 1st
> > program segment only. Not sure if this way is correct.
> > 
> > >From 40f231bb78a74caebcb4a898089a9fa5323be05f Mon Sep 17 00:00:00 2001
> > From: Baoquan He <bhe@redhat.com>
> > Date: Fri, 29 Sep 2017 21:35:30 +0800
> > Subject: [PATCH] binfmt_elf: Clean up the elf_map
> > 
> > Oleg pointed out that it's really ugly to do mmap of the total_size, then
> > unmap the region excluding the 1st segment. The right way should be search
> > an unmapped area which can cover region of total_size, then map the 1st
> > segment only.
> > 
> > And also update the code comment accordingly. In below commit, the relevant
> > code comment is not changed to cover the ELF binary image case.
> > commit a87938b2e2 ("fs/binfmt_elf.c: fix bug in loading of PIE binaries")
> > 
> > Signed-off-by: Baoquan He <bhe@redhat.com>
> > ---
> >  fs/binfmt_elf.c | 27 +++++++++++++++------------
> >  1 file changed, 15 insertions(+), 12 deletions(-)
> > 
> > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> > index 72b7ecba7ead..43a47b2aa3f6 100644
> > --- a/fs/binfmt_elf.c
> > +++ b/fs/binfmt_elf.c
> > @@ -357,22 +357,25 @@ static unsigned long elf_map(struct file *filep, unsigned long addr,
> >  		return addr;
> >  
> >  	/*
> > -	* total_size is the size of the ELF (interpreter) image.
> > -	* The _first_ mmap needs to know the full size, otherwise
> > -	* randomization might put this image into an overlapping
> > -	* position with the ELF binary image. (since size < total_size)
> > -	* So we first map the 'big' image - and unmap the remainder at
> > -	* the end. (which unmap is needed for ELF images with holes.)
> > +	* total_size is the size of the ELF binary image or the ELF loader
> > +	* image. For loader image, the _first_ mmap needs to know the full
> > +	* size, otherwise randomization might put image into an overlapping
> > +	* position with the ELF binary image.(since size < total_size)
> > +	* So we use total_size to get an area to cover the whole loader image,
> > +	* then map the 1st progment segment only with its own size. For binary
> > +	* image, similarly, the _first_ mmap also needs to know the full size,
> > +	* otherwise randomization might put image above mm->mmap_base.

Oh, no, here, it won't include the PIE binary case. Since it must be
from ELF_ET_DYN_BASE. Here should be the "ld.so program" case.

> >  	*/
> >  	if (total_size) {
> >  		total_size = ELF_PAGEALIGN(total_size);
> > -		map_addr = vm_mmap(filep, addr, total_size, prot, flags, off);
> > -		if (!BAD_ADDR(map_addr))
> > -			vm_munmap(map_addr+size, total_size-size);
> > -	} else
> > -		map_addr = vm_mmap(filep, addr, size, prot, flags, off);
> > +		addr = get_unmapped_area(file, addr, total_size, off, flags);
> 
> So how does this prevent clobbering an existing VMA when flags contains
> MAP_FIXED?

Earlier flush_old_exec() is called to clean all old VMAs. Here if
total_size is non-zero only if it's the 1st prgoram segment of dynamic
loader, either from load_elf_interp() or the "ld.so program" case. With
my understanding, it can't be meeting an existing VMA. Not sure if
it's correct. Currently, it haven't passed to ld.so to link other .so.

> 
> > +		if (offset_in_page(addr))
> > +			return addr;
> > +	}
> > +
> > +	map_addr = vm_mmap(filep, addr, size, prot, flags, off);
> >  
> > -	return(map_addr);
> > +	return (map_addr);
> >  }
> >  
> >  #endif /* !elf_map */
> > -- 
> > 2.5.5
> 
> -- 
> Michal Hocko
> SUSE Labs

  reply	other threads:[~2017-10-04 15:37 UTC|newest]

Thread overview: 39+ 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 [this message]
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 19:00         ` Michal Hocko
2017-10-16 20:02         ` James Hogan
2017-10-16 20:02           ` James Hogan
2017-10-17  7:37           ` Michal Hocko
2017-10-17  7:37             ` Michal Hocko
2017-10-17  8:35             ` James Hogan
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   ` [PATCH 2/2] fs, elf: drop MAP_FIXED from initial ET_DYN segment Michal Hocko
2017-10-16 16:44     ` 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=20171004153741.GH24886@x1 \
    --to=bhe@redhat.com \
    --cc=jkosina@suse.cz \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=mingo@elte.hu \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.