Re: [PATCH] mm: larger stack guard gap, between vmas

On Thu, Jul 06, 2017 at 10:24:06AM +0200, Willy Tarreau wrote: > On Wed, Jul 05, 2017 at 04:51:06PM -0700, Linus Torvalds wrote: > > On Wed, Jul 5, 2017 at 4:35 PM, Ben Hutchings wrote: > > >> > > >> And I think your second patch breaks that "use a really large value to > >

Re: [PATCH] mm: larger stack guard gap, between vmas

On Thu, Jul 06, 2017 at 10:24:06AM +0200, Willy Tarreau wrote: > On Wed, Jul 05, 2017 at 04:51:06PM -0700, Linus Torvalds wrote: > > On Wed, Jul 5, 2017 at 4:35 PM, Ben Hutchings wrote: > > >> > > >> And I think your second patch breaks that "use a really large value to > > >> approximate

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 04:51:06PM -0700, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 4:35 PM, Ben Hutchings wrote: > >> > >> And I think your second patch breaks that "use a really large value to > >> approximate infinity" case that definitely has existed as a pattern. >

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 04:51:06PM -0700, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 4:35 PM, Ben Hutchings wrote: > >> > >> And I think your second patch breaks that "use a really large value to > >> approximate infinity" case that definitely has existed as a pattern. > > > > Right. Well

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed 05-07-17 08:36:45, Michal Hocko wrote: > On Tue 04-07-17 16:31:52, Linus Torvalds wrote: > > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings wrote: > > > > > > We have: > > > > > > bottom = 0xff803fff > > > sp = 0xb178 > > > > > > The relevant mappings are: > >

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed 05-07-17 08:36:45, Michal Hocko wrote: > On Tue 04-07-17 16:31:52, Linus Torvalds wrote: > > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings wrote: > > > > > > We have: > > > > > > bottom = 0xff803fff > > > sp = 0xb178 > > > > > > The relevant mappings are: > > > > > >

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 04:23:56PM +0200, Michal Hocko wrote: > On Wed 05-07-17 13:19:40, Ben Hutchings wrote: > > On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote: > > > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings > > > wrote: > > > > > > > > We have: > > > > > >

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 04:23:56PM +0200, Michal Hocko wrote: > On Wed 05-07-17 13:19:40, Ben Hutchings wrote: > > On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote: > > > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings > > > wrote: > > > > > > > > We have: > > > > > > > > bottom =

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 05:19:47PM -0700, Andy Lutomirski wrote: > I think it's ridiculous that you can change rlimits and then > exec a setuid thing. It's not so easy to fix, though. Maybe track, > per-task, inherited by clone and exec, what the rlimits were the last > time the process had

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 05:19:47PM -0700, Andy Lutomirski wrote: > I think it's ridiculous that you can change rlimits and then > exec a setuid thing. It's not so easy to fix, though. Maybe track, > per-task, inherited by clone and exec, what the rlimits were the last > time the process had

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 5:19 PM, Andy Lutomirski wrote: > On Wed, Jul 5, 2017 at 4:50 PM, Kees Cook wrote: >> As part of that should we put restrictions on the environment of >> set*id exec too? Part of the risks demonstrated by Qualys was that >> allowing

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 5:19 PM, Andy Lutomirski wrote: > On Wed, Jul 5, 2017 at 4:50 PM, Kees Cook wrote: >> As part of that should we put restrictions on the environment of >> set*id exec too? Part of the risks demonstrated by Qualys was that >> allowing a privilege-elevating binary to inherit

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 5:31 PM, Andy Lutomirski wrote: > > I wonder if we could pull some "sane" values out of our arses and have > it work just fine. That approach may work, but it's pretty nasty. But together with at least some way for the distro to set the values we pick, it

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 5:31 PM, Andy Lutomirski wrote: > > I wonder if we could pull some "sane" values out of our arses and have > it work just fine. That approach may work, but it's pretty nasty. But together with at least some way for the distro to set the values we pick, it would probably

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 4:55 PM, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 4:50 PM, Kees Cook wrote: >> >> As part of that should we put restrictions on the environment of >> set*id exec too? > > I'm not seeing what sane limits you could

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 4:55 PM, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 4:50 PM, Kees Cook wrote: >> >> As part of that should we put restrictions on the environment of >> set*id exec too? > > I'm not seeing what sane limits you could use. > > I think the concept of "reset as much of the

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 4:50 PM, Ben Hutchings wrote: > On Wed, 2017-07-05 at 13:53 -0700, Andy Lutomirski wrote: >> On Jul 5, 2017, at 12:32 PM, Ben Hutchings wrote: >> > On Wed, 2017-07-05 at 10:23 -0700, Andy Lutomirski wrote: > [...] >> > > - As a

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 4:50 PM, Ben Hutchings wrote: > On Wed, 2017-07-05 at 13:53 -0700, Andy Lutomirski wrote: >> On Jul 5, 2017, at 12:32 PM, Ben Hutchings wrote: >> > On Wed, 2017-07-05 at 10:23 -0700, Andy Lutomirski wrote: > [...] >> > > - As a hardening feature, if the stack would expand

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 4:50 PM, Kees Cook wrote: > On Wed, Jul 5, 2017 at 10:23 AM, Andy Lutomirski wrote: >> Right. But I think the approach that we're all taking here is a bit >> nutty. We all realize that this issue is a longstanding *GCC* bug >> [1],

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 4:50 PM, Kees Cook wrote: > On Wed, Jul 5, 2017 at 10:23 AM, Andy Lutomirski wrote: >> Right. But I think the approach that we're all taking here is a bit >> nutty. We all realize that this issue is a longstanding *GCC* bug >> [1], but we're acting like it's a Big Deal

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 4:50 PM, Kees Cook wrote: > > As part of that should we put restrictions on the environment of > set*id exec too? I'm not seeing what sane limits you could use. I think the concept of "reset as much of the environment to sane things when running

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 4:50 PM, Kees Cook wrote: > > As part of that should we put restrictions on the environment of > set*id exec too? I'm not seeing what sane limits you could use. I think the concept of "reset as much of the environment to sane things when running suid binaries" is a good

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, 2017-07-05 at 13:53 -0700, Andy Lutomirski wrote: > On Jul 5, 2017, at 12:32 PM, Ben Hutchings wrote: > > On Wed, 2017-07-05 at 10:23 -0700, Andy Lutomirski wrote: [...] > > >  - As a hardening feature, if the stack would expand within 64k or > > > whatever of a

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, 2017-07-05 at 13:53 -0700, Andy Lutomirski wrote: > On Jul 5, 2017, at 12:32 PM, Ben Hutchings wrote: > > On Wed, 2017-07-05 at 10:23 -0700, Andy Lutomirski wrote: [...] > > >  - As a hardening feature, if the stack would expand within 64k or > > > whatever of a non-MAP_FIXED mapping,

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 4:35 PM, Ben Hutchings wrote: >> >> And I think your second patch breaks that "use a really large value to >> approximate infinity" case that definitely has existed as a pattern. > > Right. Well that seems to leave us with remembering the MAP_FIXED

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 4:35 PM, Ben Hutchings wrote: >> >> And I think your second patch breaks that "use a really large value to >> approximate infinity" case that definitely has existed as a pattern. > > Right. Well that seems to leave us with remembering the MAP_FIXED flag > and using that as

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 10:23 AM, Andy Lutomirski wrote: > Right. But I think the approach that we're all taking here is a bit > nutty. We all realize that this issue is a longstanding *GCC* bug > [1], but we're acting like it's a Big Deal (tm) kernel bug that Must > Be Fixed

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 10:23 AM, Andy Lutomirski wrote: > Right. But I think the approach that we're all taking here is a bit > nutty. We all realize that this issue is a longstanding *GCC* bug > [1], but we're acting like it's a Big Deal (tm) kernel bug that Must > Be Fixed (tm) and therefore

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, 2017-07-05 at 10:15 -0700, Linus Torvalds wrote: > > On Wed, Jul 5, 2017 at 9:58 AM, Ben Hutchings wrote: > > > > I ended up with the following two patches, which seem to deal with > > both the Java and Rust regressions.  These don't touch the > > stack-grows-up

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, 2017-07-05 at 10:15 -0700, Linus Torvalds wrote: > > On Wed, Jul 5, 2017 at 9:58 AM, Ben Hutchings wrote: > > > > I ended up with the following two patches, which seem to deal with > > both the Java and Rust regressions.  These don't touch the > > stack-grows-up paths at all because Rust

Re: [PATCH] mm: larger stack guard gap, between vmas

> On Jul 5, 2017, at 12:32 PM, Ben Hutchings wrote: > >> On Wed, 2017-07-05 at 10:23 -0700, Andy Lutomirski wrote: >> [...] >> Looking at it that way, I think a new inherited-on-exec flag is nucking futs. >> >> I'm starting to think that the right approach is to mostly

Re: [PATCH] mm: larger stack guard gap, between vmas

> On Jul 5, 2017, at 12:32 PM, Ben Hutchings wrote: > >> On Wed, 2017-07-05 at 10:23 -0700, Andy Lutomirski wrote: >> [...] >> Looking at it that way, I think a new inherited-on-exec flag is nucking futs. >> >> I'm starting to think that the right approach is to mostly revert all >> this

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 08:32:43PM +0100, Ben Hutchings wrote: > >  - As a hardening feature, if the stack would expand within 64k or > > whatever of a non-MAP_FIXED mapping, refuse to expand it.  (This might > > have to be a non-hinted mapping, not just a non-MAP_FIXED mapping.) > > The idea

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 08:32:43PM +0100, Ben Hutchings wrote: > >  - As a hardening feature, if the stack would expand within 64k or > > whatever of a non-MAP_FIXED mapping, refuse to expand it.  (This might > > have to be a non-hinted mapping, not just a non-MAP_FIXED mapping.) > > The idea

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, 2017-07-05 at 10:23 -0700, Andy Lutomirski wrote: [...] > Looking at it that way, I think a new inherited-on-exec flag is nucking futs. > > I'm starting to think that the right approach is to mostly revert all > this stuff (the execve fixes are fine).  Then start over and think > about it

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, 2017-07-05 at 10:23 -0700, Andy Lutomirski wrote: [...] > Looking at it that way, I think a new inherited-on-exec flag is nucking futs. > > I'm starting to think that the right approach is to mostly revert all > this stuff (the execve fixes are fine).  Then start over and think > about it

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 12:18 PM, Willy Tarreau wrote: > > But only if the sysctl is set. It can simply be recommended to set it > if any program fails. We've done this for many years with other ones > like min_mmap_addr or tcp_ecn. Ok, fair enough. I don't hate the approach, and

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 12:18 PM, Willy Tarreau wrote: > > But only if the sysctl is set. It can simply be recommended to set it > if any program fails. We've done this for many years with other ones > like min_mmap_addr or tcp_ecn. Ok, fair enough. I don't hate the approach, and maybe it's

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 12:17:20PM -0700, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 11:59 AM, Willy Tarreau wrote: > > > > Don't you think that the option of having a sysctl to relax the check > > per task wouldn't be easier for distros and safer overall ? Ie, emit > > a warning

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 12:17:20PM -0700, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 11:59 AM, Willy Tarreau wrote: > > > > Don't you think that the option of having a sysctl to relax the check > > per task wouldn't be easier for distros and safer overall ? Ie, emit > > a warning the first

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 11:59 AM, Willy Tarreau wrote: > > Don't you think that the option of having a sysctl to relax the check > per task wouldn't be easier for distros and safer overall ? Ie, emit > a warning the first time the gap is hit instead of segfaulting, then > reduce it to

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 11:59 AM, Willy Tarreau wrote: > > Don't you think that the option of having a sysctl to relax the check > per task wouldn't be easier for distros and safer overall ? Ie, emit > a warning the first time the gap is hit instead of segfaulting, then > reduce it to something

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 09:17:59AM -0700, Linus Torvalds wrote: (...) > The good news is that this is probably specialized enough that we can > just keep the defaults as "will break this one case, but we give > people the tools to work around it". > > I hate doing that, but distros that still

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 09:17:59AM -0700, Linus Torvalds wrote: (...) > The good news is that this is probably specialized enough that we can > just keep the defaults as "will break this one case, but we give > people the tools to work around it". > > I hate doing that, but distros that still

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, 2017-07-05 at 19:05 +0200, Michal Hocko wrote: > On Wed 05-07-17 17:58:45, Ben Hutchings wrote: > [...] > > diff --git a/mm/mmap.c b/mm/mmap.c > > index c7906ae1a7a1..f8131a94e56e 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -2307,6 +2307,25 @@ int expand_upwards(struct

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, 2017-07-05 at 19:05 +0200, Michal Hocko wrote: > On Wed 05-07-17 17:58:45, Ben Hutchings wrote: > [...] > > diff --git a/mm/mmap.c b/mm/mmap.c > > index c7906ae1a7a1..f8131a94e56e 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -2307,6 +2307,25 @@ int expand_upwards(struct

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 9:20 AM, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 9:15 AM, Andy Lutomirski wrote: >> On Wed, Jul 5, 2017 at 7:23 AM, Michal Hocko wrote: >>> >>> This is really worrying. This doesn't look like a gap

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 9:20 AM, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 9:15 AM, Andy Lutomirski wrote: >> On Wed, Jul 5, 2017 at 7:23 AM, Michal Hocko wrote: >>> >>> This is really worrying. This doesn't look like a gap at all. It is a >>> mapping which actually contains a code and so

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 9:58 AM, Ben Hutchings wrote: > > I ended up with the following two patches, which seem to deal with > both the Java and Rust regressions. These don't touch the > stack-grows-up paths at all because Rust doesn't run on those > architectures and the

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 9:58 AM, Ben Hutchings wrote: > > I ended up with the following two patches, which seem to deal with > both the Java and Rust regressions. These don't touch the > stack-grows-up paths at all because Rust doesn't run on those > architectures and the Java weirdness is

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed 05-07-17 17:58:45, Ben Hutchings wrote: [...] > diff --git a/mm/mmap.c b/mm/mmap.c > index c7906ae1a7a1..f8131a94e56e 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -2307,6 +2307,25 @@ int expand_upwards(struct vm_area_struct *vma, > unsigned long address) > } > #endif /*

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed 05-07-17 17:58:45, Ben Hutchings wrote: [...] > diff --git a/mm/mmap.c b/mm/mmap.c > index c7906ae1a7a1..f8131a94e56e 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -2307,6 +2307,25 @@ int expand_upwards(struct vm_area_struct *vma, > unsigned long address) > } > #endif /*

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 04:25:00PM +0100, Ben Hutchings wrote: [...] > Soemthing I noticed is that Java doesn't immediately use MAP_FIXED. > Look at os::pd_attempt_reserve_memory_at(). If the first, hinted, > mmap() doesn't return the hinted address it then attempts to allocate > huge areas (I'm

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 04:25:00PM +0100, Ben Hutchings wrote: [...] > Soemthing I noticed is that Java doesn't immediately use MAP_FIXED. > Look at os::pd_attempt_reserve_memory_at(). If the first, hinted, > mmap() doesn't return the hinted address it then attempts to allocate > huge areas (I'm

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 9:15 AM, Andy Lutomirski wrote: > On Wed, Jul 5, 2017 at 7:23 AM, Michal Hocko wrote: >> >> This is really worrying. This doesn't look like a gap at all. It is a >> mapping which actually contains a code and so we should absolutely not

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 9:15 AM, Andy Lutomirski wrote: > On Wed, Jul 5, 2017 at 7:23 AM, Michal Hocko wrote: >> >> This is really worrying. This doesn't look like a gap at all. It is a >> mapping which actually contains a code and so we should absolutely not >> allow to scribble over it. So I am

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 5:19 AM, Ben Hutchings wrote: > On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote: >> >> Can you find out where that is allocated? Perhaps a breakpoint on >> mmap, with a condition to catch that particular one? > > Found it, and it's now clear

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 5:19 AM, Ben Hutchings wrote: > On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote: >> >> Can you find out where that is allocated? Perhaps a breakpoint on >> mmap, with a condition to catch that particular one? > > Found it, and it's now clear why only i386 is

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 7:23 AM, Michal Hocko wrote: > On Wed 05-07-17 13:19:40, Ben Hutchings wrote: >> On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote: >> > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings >> > wrote: >> > > >> > > We have: >> > >

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 7:23 AM, Michal Hocko wrote: > On Wed 05-07-17 13:19:40, Ben Hutchings wrote: >> On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote: >> > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings >> > wrote: >> > > >> > > We have: >> > > >> > > bottom = 0xff803fff >> > > sp =

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 5:21 AM, Ben Hutchings wrote: > > How about, instead of looking at permissions, we remember whether vmas > were allocated with MAP_FIXED and ignore those when evaluating the gap? No, I think that's a bad idea. There's tons of good reasons to use

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 5:21 AM, Ben Hutchings wrote: > > How about, instead of looking at permissions, we remember whether vmas > were allocated with MAP_FIXED and ignore those when evaluating the gap? No, I think that's a bad idea. There's tons of good reasons to use MAP_FIXED, and real

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed 05-07-17 16:25:00, Ben Hutchings wrote: > On Wed, 2017-07-05 at 16:23 +0200, Michal Hocko wrote: > > On Wed 05-07-17 13:19:40, Ben Hutchings wrote: > > > On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote: > > > > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings > >

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed 05-07-17 16:25:00, Ben Hutchings wrote: > On Wed, 2017-07-05 at 16:23 +0200, Michal Hocko wrote: > > On Wed 05-07-17 13:19:40, Ben Hutchings wrote: > > > On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote: > > > > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings > > > > wrote: > > > > >

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, 2017-07-05 at 16:23 +0200, Michal Hocko wrote: > On Wed 05-07-17 13:19:40, Ben Hutchings wrote: > > On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote: > > > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings > > > wrote: > > > > > > > > We have: > > > > > > > >

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, 2017-07-05 at 16:23 +0200, Michal Hocko wrote: > On Wed 05-07-17 13:19:40, Ben Hutchings wrote: > > On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote: > > > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings > > > wrote: > > > > > > > > We have: > > > > > > > > bottom = 0xff803fff > >

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed 05-07-17 13:19:40, Ben Hutchings wrote: > On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote: > > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings > > wrote: > > > > > > We have: > > > > > > bottom = 0xff803fff > > > sp = 0xb178 > > > > > > The relevant

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed 05-07-17 13:19:40, Ben Hutchings wrote: > On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote: > > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings > > wrote: > > > > > > We have: > > > > > > bottom = 0xff803fff > > > sp = 0xb178 > > > > > > The relevant mappings are: > > > >

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed 05-07-17 13:21:54, 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

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed 05-07-17 13:21:54, 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

Re: [vs-plain] Re: [PATCH] mm: larger stack guard gap, between vmas

Hi all, On Tue, Jul 04, 2017 at 07:16:06PM -0600, kseifr...@redhat.com wrote: > This issue occurs post stackguard patches correct? Fixing it sounds like > this might go beyond hardening and into CVE territory. Since this thread is public on LKML, as it should be, it's no longer valid to be CC'ed

Re: [vs-plain] Re: [PATCH] mm: larger stack guard gap, between vmas

Hi all, On Tue, Jul 04, 2017 at 07:16:06PM -0600, kseifr...@redhat.com wrote: > This issue occurs post stackguard patches correct? Fixing it sounds like > this might go beyond hardening and into CVE territory. Since this thread is public on LKML, as it should be, it's no longer valid to be CC'ed

Re: [PATCH] mm: larger stack guard gap, between vmas

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

Re: [PATCH] mm: larger stack guard gap, between vmas

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

Re: [PATCH] mm: larger stack guard gap, between vmas

On Tue, 2017-07-04 at 09:18 -0700, Linus Torvalds wrote: > > On Tue, Jul 4, 2017 at 4:36 AM, Ben Hutchings wrote: > > > > That's what I was thinking of.  Tried the following patch: > > > > Subject: mmap: Ignore VM_NONE mappings when checking for space to > >  expand the

Re: [PATCH] mm: larger stack guard gap, between vmas

On Tue, 2017-07-04 at 09:18 -0700, Linus Torvalds wrote: > > On Tue, Jul 4, 2017 at 4:36 AM, Ben Hutchings wrote: > > > > That's what I was thinking of.  Tried the following patch: > > > > Subject: mmap: Ignore VM_NONE mappings when checking for space to > >  expand the stack > > This looks

Re: [PATCH] mm: larger stack guard gap, between vmas

On Tue, 2017-07-04 at 19:11 +0200, Willy Tarreau wrote: > On Tue, Jul 04, 2017 at 12:36:11PM +0100, Ben Hutchings wrote: > > @@ -2323,11 +2330,17 @@ int expand_downwards(struct vm_area_struct *vma, > >   if (error) > >   return error; > >   > > - /* Enforce stack_guard_gap */ > > +

Re: [PATCH] mm: larger stack guard gap, between vmas

On Tue, 2017-07-04 at 19:11 +0200, Willy Tarreau wrote: > On Tue, Jul 04, 2017 at 12:36:11PM +0100, Ben Hutchings wrote: > > @@ -2323,11 +2330,17 @@ int expand_downwards(struct vm_area_struct *vma, > >   if (error) > >   return error; > >   > > - /* Enforce stack_guard_gap */ > > +

Re: [PATCH] mm: larger stack guard gap, between vmas

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

Re: [PATCH] mm: larger stack guard gap, between vmas

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

Re: [PATCH] mm: larger stack guard gap, between vmas

On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote: > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings > wrote: > > > > We have: > > > > bottom = 0xff803fff > > sp = 0xb178 > > > > The relevant mappings are: > > > > ff7fc000-ff7fd000 rwxp 00:00 0 > >

Re: [PATCH] mm: larger stack guard gap, between vmas

On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote: > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings > wrote: > > > > We have: > > > > bottom = 0xff803fff > > sp = 0xb178 > > > > The relevant mappings are: > > > > ff7fc000-ff7fd000 rwxp 00:00 0 > > fffdd000-e000 rw-p

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 10:24:41AM +0200, Michal Hocko wrote: > > 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. > > Yes, this is what my patch

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 10:24:41AM +0200, Michal Hocko wrote: > > 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. > > Yes, this is what my patch

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed 05-07-17 10:14:43, 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. > >

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed 05-07-17 10:14:43, 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. > >

Re: [PATCH] mm: larger stack guard gap, between vmas

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

Re: [PATCH] mm: larger stack guard gap, between vmas

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

Re: [PATCH] mm: larger stack guard gap, between vmas

On Tue 04-07-17 16:31:52, Linus Torvalds wrote: > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings wrote: > > > > We have: > > > > bottom = 0xff803fff > > sp = 0xb178 > > > > The relevant mappings are: > > > > ff7fc000-ff7fd000 rwxp 00:00 0 > >

Re: [PATCH] mm: larger stack guard gap, between vmas

On Tue 04-07-17 16:31:52, Linus Torvalds wrote: > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings wrote: > > > > We have: > > > > bottom = 0xff803fff > > sp = 0xb178 > > > > The relevant mappings are: > > > > ff7fc000-ff7fd000 rwxp 00:00 0 > > fffdd000-e000 rw-p 00:00

Re: [vs-plain] Re: [PATCH] mm: larger stack guard gap, between vmas

This issue occurs post stackguard patches correct? Fixing it sounds like this might go beyond hardening and into CVE territory. -- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 Red Hat Product Security contact: secal...@redhat.com

Re: [vs-plain] Re: [PATCH] mm: larger stack guard gap, between vmas

This issue occurs post stackguard patches correct? Fixing it sounds like this might go beyond hardening and into CVE territory. -- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 Red Hat Product Security contact: secal...@redhat.com

Re: [PATCH] mm: larger stack guard gap, between vmas

On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings wrote: > > We have: > > bottom = 0xff803fff > sp = 0xb178 > > The relevant mappings are: > > ff7fc000-ff7fd000 rwxp 00:00 0 > fffdd000-e000 rw-p 00:00 0 > [stack]

Re: [PATCH] mm: larger stack guard gap, between vmas

On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings wrote: > > We have: > > bottom = 0xff803fff > sp = 0xb178 > > The relevant mappings are: > > ff7fc000-ff7fd000 rwxp 00:00 0 > fffdd000-e000 rw-p 00:00 0 > [stack] Ugh. So that stack is

Re: [PATCH] mm: larger stack guard gap, between vmas

On Tue, 2017-07-04 at 12:36 +0100, Ben Hutchings wrote: [...] > This *doesn't* fix the LibreOffice regression on i386. gdb shows me that the crash is at the last statement in this function: static void _expand_stack_to(address bottom) {   address sp;   size_t size;   volatile char *p;   //

Re: [PATCH] mm: larger stack guard gap, between vmas

On Tue, 2017-07-04 at 12:36 +0100, Ben Hutchings wrote: [...] > This *doesn't* fix the LibreOffice regression on i386. gdb shows me that the crash is at the last statement in this function: static void _expand_stack_to(address bottom) {   address sp;   size_t size;   volatile char *p;   //

Re: [PATCH] mm: larger stack guard gap, between vmas

On Tue, Jul 04, 2017 at 11:47:37AM -0700, Linus Torvalds wrote: > Let's > say that you are using lots of threads, so that you know your stack > space is limited. What you do is to use MAP_FIXED a lot, and you lay > out your stacks fairly densely (with each other, but also possibly > with other

Re: [PATCH] mm: larger stack guard gap, between vmas

On Tue, Jul 04, 2017 at 11:47:37AM -0700, Linus Torvalds wrote: > Let's > say that you are using lots of threads, so that you know your stack > space is limited. What you do is to use MAP_FIXED a lot, and you lay > out your stacks fairly densely (with each other, but also possibly > with other

Re: [PATCH] mm: larger stack guard gap, between vmas

On Tue, Jul 4, 2017 at 11:39 AM, Willy Tarreau wrote: > > But what is wrong with stopping the loop as soon as the distance gets > larger than the stack_guard_gap ? Absolutely nothing. But that's not the problem with the loop. Let's say that you are using lots of threads, so that you

Re: [PATCH] mm: larger stack guard gap, between vmas

On Tue, Jul 4, 2017 at 11:39 AM, Willy Tarreau wrote: > > But what is wrong with stopping the loop as soon as the distance gets > larger than the stack_guard_gap ? Absolutely nothing. But that's not the problem with the loop. Let's say that you are using lots of threads, so that you know your

  1   2   >