All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: Michal Hocko <mhocko@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Hugh Dickins <hughd@google.com>, Oleg Nesterov <oleg@redhat.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Rik van Riel <riel@redhat.com>,
	Larry Woodman <lwoodman@redhat.com>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	Tony Luck <tony.luck@intel.com>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Helge Diller <deller@gmx.de>,
	James Hogan <james.hogan@imgtec.com>,
	Laura Abbott <labbott@redhat.com>, Greg KH <greg@kroah.com>,
	"security@kernel.org" <security@kernel.org>,
	linux-distros@vs.openwall.org,
	Qualys Security Advisory <qsa@qualys.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Ximin Luo <infinity0@debian.org>
Subject: Re: [PATCH] mm: larger stack guard gap, between vmas
Date: Wed, 5 Jul 2017 15:52:34 +0200	[thread overview]
Message-ID: <20170705135234.GB24265@1wt.eu> (raw)
In-Reply-To: <1499257314.2707.36.camel@decadent.org.uk>

On Wed, Jul 05, 2017 at 01:21:54PM +0100, Ben Hutchings wrote:
> On Wed, 2017-07-05 at 10:14 +0200, Willy Tarreau wrote:
> > On Wed, Jul 05, 2017 at 08:36:46AM +0200, Michal Hocko wrote:
> > > PROT_NONE would explicitly fault but we would simply
> > > run over this mapping too easily and who knows what might end up below
> > > it. So to me the guard gap does its job here.
> > 
> > I tend to think that applications that implement their own stack guard
> > using PROT_NONE also assume that they will never perfom unchecked stack
> > allocations larger than their own guard, thus the condition above should
> > never happen. Otherwise they're bogus and/or vulnerable by design and it
> > is their responsibility to fix it.
> > 
> > Thus maybe if that helps we could even relax some of the stack guard
> > checks as soon as we meet a PROT_NONE area, allowing VMAs to be tightly
> > packed if the application knows what it's doing. That wouldn't solve
> > the libreoffice issue though, given the lower page is RWX.
> 
> How about, instead of looking at permissions, we remember whether vmas
> were allocated with MAP_FIXED and ignore those when evaluating the gap?

I like this idea. It leaves complete control to the application. Our
usual principle of letting people shoot themselves in the foot if they
insist on doing so.

Do you think something like this could work (not even build tested) ?

Willy
--

diff --git a/include/linux/mm.h b/include/linux/mm.h
index d16f524..8ad7f40 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -90,6 +90,7 @@
 #define VM_PFNMAP	0x00000400	/* Page-ranges managed without "struct page", just pure PFN */
 #define VM_DENYWRITE	0x00000800	/* ETXTBSY on write attempts.. */
 
+#define VM_FIXED	0x00001000	/* MAP_FIXED was used */
 #define VM_LOCKED	0x00002000
 #define VM_IO           0x00004000	/* Memory mapped I/O or similar */
 
diff --git a/include/linux/mman.h b/include/linux/mman.h
index 9aa863d..4df2659 100644
--- a/include/linux/mman.h
+++ b/include/linux/mman.h
@@ -79,6 +79,7 @@ static inline int arch_validate_prot(unsigned long prot)
 {
 	return _calc_vm_trans(flags, MAP_GROWSDOWN,  VM_GROWSDOWN ) |
 	       _calc_vm_trans(flags, MAP_DENYWRITE,  VM_DENYWRITE ) |
+	       _calc_vm_trans(flags, MAP_FIXED,      VM_FIXED     ) |
 	       _calc_vm_trans(flags, MAP_LOCKED,     VM_LOCKED    );
 }
 #endif /* _LINUX_MMAN_H */
diff --git a/mm/mmap.c b/mm/mmap.c
index 3c4e4d7..b612868 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2145,7 +2145,7 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address)
 
 	next = vma->vm_next;
 	if (next && next->vm_start < gap_addr) {
-		if (!(next->vm_flags & VM_GROWSUP))
+		if (!(next->vm_flags & (VM_GROWSUP|VM_FIXED)))
 			return -ENOMEM;
 		/* Check that both stack segments have the same anon_vma? */
 	}
@@ -2225,7 +2225,7 @@ int expand_downwards(struct vm_area_struct *vma,
 		return -ENOMEM;
 	prev = vma->vm_prev;
 	if (prev && prev->vm_end > gap_addr) {
-		if (!(prev->vm_flags & VM_GROWSDOWN))
+		if (!(prev->vm_flags & (VM_GROWSDOWN|VM_FIXED)))
 			return -ENOMEM;
 		/* Check that both stack segments have the same anon_vma? */
 	}

  reply	other threads:[~2017-07-05 13:53 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <alpine.LSU.2.11.1706190355140.2626@eggly.anvils>
2017-06-22 12:30 ` [PATCH] mm: larger stack guard gap, between vmas Ben Hutchings
2017-06-22 12:46   ` Willy Tarreau
2017-06-22 12:58     ` Ben Hutchings
2017-06-22 13:10       ` Willy Tarreau
2017-06-22 13:10         ` Willy Tarreau
2017-06-22 13:28         ` Willy Tarreau
2017-06-22 13:28           ` Willy Tarreau
2017-06-22 13:15       ` [vs-plain] " Levente Polyak
2017-06-22 13:59         ` Willy Tarreau
2017-06-22 14:14           ` Ben Hutchings
2017-06-22 14:34             ` Willy Tarreau
2017-06-23  3:10               ` Andy Lutomirski
2017-06-23  4:42                 ` Linus Torvalds
2017-06-22 21:23             ` Helge Deller
2017-06-23  4:35   ` Hugh Dickins
2017-06-24  9:11     ` Hugh Dickins
2017-06-24 18:29       ` Ben Hutchings
     [not found] ` <CA+55aFx6j4na3BVRC2aQuf-kNp1jzGahN8To_SFpNu+H=gopJA@mail.gmail.com>
     [not found]   ` <20170619142358.GA32654@1wt.eu>
     [not found]     ` <1498009101.2655.6.camel@decadent.org.uk>
     [not found]       ` <20170621092419.GA22051@dhcp22.suse.cz>
     [not found]         ` <1498042057.2655.8.camel@decadent.org.uk>
2017-07-03 23:55           ` Ben Hutchings
2017-07-04  0:05             ` Linus Torvalds
2017-07-04  8:41               ` Michal Hocko
2017-07-04  9:35                 ` Michal Hocko
2017-07-04  9:47                   ` Willy Tarreau
2017-07-04 10:42                     ` Michal Hocko
2017-07-04 11:36                       ` Ben Hutchings
2017-07-04 12:00                         ` Michal Hocko
2017-07-04 12:11                           ` Michal Hocko
2017-07-04 12:21                           ` Ben Hutchings
2017-07-04 12:33                             ` Michal Hocko
2017-07-04 14:19                               ` Ximin Luo
2017-07-04 14:48                                 ` Michal Hocko
2017-07-04 15:51                         ` Willy Tarreau
2017-07-04 17:22                           ` Michal Hocko
2017-07-04 18:37                             ` Linus Torvalds
2017-07-04 18:39                               ` Willy Tarreau
2017-07-04 18:47                                 ` Linus Torvalds
2017-07-04 19:03                                   ` Willy Tarreau
2017-07-04 16:18                         ` Linus Torvalds
2017-07-04 16:27                           ` John Haxby
2017-07-04 17:02                             ` Willy Tarreau
2017-07-05 12:26                           ` Ben Hutchings
2017-07-04 17:11                         ` Willy Tarreau
2017-07-05 12:25                           ` Ben Hutchings
2017-07-04 23:01                         ` Ben Hutchings
2017-07-04 23:31                           ` Linus Torvalds
2017-07-05  6:36                             ` Michal Hocko
2017-07-05  8:14                               ` Willy Tarreau
2017-07-05  8:24                                 ` Michal Hocko
2017-07-05  9:15                                   ` Willy Tarreau
2017-07-05 12:21                                 ` Ben Hutchings
2017-07-05 13:52                                   ` Willy Tarreau [this message]
2017-07-05 14:19                                   ` Michal Hocko
2017-07-05 16:06                                   ` Linus Torvalds
2017-07-06  7:34                               ` Michal Hocko
2017-07-05 12:19                             ` Ben Hutchings
2017-07-05 14:23                               ` Michal Hocko
2017-07-05 15:25                                 ` Ben Hutchings
2017-07-05 15:59                                   ` Michal Hocko
2017-07-05 16:58                                   ` Ben Hutchings
2017-07-05 17:05                                     ` Michal Hocko
2017-07-05 17:24                                       ` Ben Hutchings
2017-07-05 17:15                                     ` Linus Torvalds
2017-07-05 23:35                                       ` Ben Hutchings
2017-07-05 23:51                                         ` Linus Torvalds
2017-07-06  8:24                                           ` Willy Tarreau
2017-07-06 10:11                                             ` Willy Tarreau
2017-07-10  2:40                                     ` [lkp-robot] [mm] a99d848d3b: kernel_BUG_at_mm/mmap.c kernel test robot
2017-07-10  2:40                                       ` kernel test robot
2017-07-05 16:15                                 ` [PATCH] mm: larger stack guard gap, between vmas Andy Lutomirski
2017-07-05 16:20                                   ` Linus Torvalds
2017-07-05 17:23                                     ` Andy Lutomirski
2017-07-05 19:32                                       ` Ben Hutchings
2017-07-05 20:40                                         ` Willy Tarreau
2017-07-05 20:53                                         ` Andy Lutomirski
2017-07-05 23:50                                           ` Ben Hutchings
2017-07-06  0:23                                             ` Andy Lutomirski
2017-07-05 23:50                                       ` Kees Cook
2017-07-05 23:55                                         ` Linus Torvalds
2017-07-06  0:31                                           ` Andy Lutomirski
2017-07-06  0:47                                             ` Linus Torvalds
2017-07-06  0:19                                         ` Andy Lutomirski
2017-07-06  2:45                                           ` Kees Cook
2017-07-06  5:23                                           ` Willy Tarreau
2017-07-06  5:33                                 ` Kevin Easton
2017-07-05 16:17                               ` Linus Torvalds
2017-07-05 18:59                                 ` Willy Tarreau
2017-07-05 19:17                                   ` Linus Torvalds
2017-07-05 19:18                                     ` Willy Tarreau
2017-07-05 19:21                                       ` Linus Torvalds
2017-07-05  1:16                           ` [vs-plain] " kseifried
2017-07-05 14:11                             ` Solar Designer
2017-07-04 10:46                   ` Michal Hocko
2017-07-04 10:51                     ` Michal Hocko
2017-07-04  0:27             ` Andy Lutomirski
2017-07-04 12:26             ` [vs-plain] " John Haxby

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=20170705135234.GB24265@1wt.eu \
    --to=w@1wt.eu \
    --cc=Jason@zx2c4.com \
    --cc=ben@decadent.org.uk \
    --cc=deller@gmx.de \
    --cc=greg@kroah.com \
    --cc=hughd@google.com \
    --cc=infinity0@debian.org \
    --cc=james.hogan@imgtec.com \
    --cc=jejb@parisc-linux.org \
    --cc=kirill@shutemov.name \
    --cc=labbott@redhat.com \
    --cc=linux-distros@vs.openwall.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lwoodman@redhat.com \
    --cc=mhocko@kernel.org \
    --cc=oleg@redhat.com \
    --cc=qsa@qualys.com \
    --cc=riel@redhat.com \
    --cc=security@kernel.org \
    --cc=tony.luck@intel.com \
    --cc=torvalds@linux-foundation.org \
    /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.