All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.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>
Subject: Re: [PATCH 2/2] fs, elf: drop MAP_FIXED from initial ET_DYN segment
Date: Thu, 19 Oct 2017 13:20:01 +0200	[thread overview]
Message-ID: <20171019112001.fjqxazjb6sargrqa@dhcp22.suse.cz> (raw)
In-Reply-To: <CAGXu5jLZHJoBrNK-SUdih181R+vC=TO9jm-4xeJQC8=UGxzQ4Q@mail.gmail.com>

On Tue 17-10-17 13:01:04, Kees Cook wrote:
> On Tue, Oct 17, 2017 at 2:04 AM, Michal Hocko <mhocko@kernel.org> wrote:
[...]
> > I am not insisting on this patch but it seems to me is just makes a
> > recoverable state a failure.
> 
> Right, I understand you're trying to make it recoverable. I'm
> suggesting that making it recoverable provides a way for an attack to
> abuse it, and that what we'd be recovering from is a case we should
> never ever see.
> 
> Consider the case where through some future bug/feature, it's possible
> to put the stack at an arbitrary location during an exec. (We've
> worked to fix that already, but who knows what the future holds either
> through misfeatures or bugs.) If an attacker maps the stack over a
> large portion of the PIE exec range, patch 2 will result in vmmap
> searching out a location that isn't already allocated. This means that
> instead of the PIE ASLR choosing from the entire possible range, it
> will get limited to only the area where something isn't already
> overlapping. This would give an attacker the ability to control the
> PIE ASLR, possibly forcing it into a fixed location.

Yes, I guess I understand that part. What is not clear to me exactly is
why this matters as we have the mmap_base randomized and not under the
control of the attacker.

-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2017-10-19 11:20 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
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 [this message]
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=20171019112001.fjqxazjb6sargrqa@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=bhe@redhat.com \
    --cc=jkosina@suse.cz \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 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.