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 infinity
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 tha
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:
> > >
> > > ff7fc000-ff7fd0
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 = 0xff803ff
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 privi
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 r
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 be
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 e
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
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 (t
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 co
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, refu
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
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 i
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
> 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 stuff
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 being
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
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 simple
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 tim
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 tha
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 supp
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 vm_area_str
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 we
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 i386-sp
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 /* CONFIG_STACK_GR
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
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
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 affected
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 =
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 programs
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:
> > > > >
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
> > >
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:
> > >
> >
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 u
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
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
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 san
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 */
> > +
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 her
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 0
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 doe
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.
>
> I
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 s
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 0
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
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 ac
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;
// Adjus
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 mapp
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 sta
On Tue, Jul 04, 2017 at 11:37:15AM -0700, Linus Torvalds wrote:
> On Tue, Jul 4, 2017 at 10:22 AM, Michal Hocko wrote:
> >
> > Well, I've been thinking about this some more and the more I think about
> > it the less I am convinced we should try to be clever here. Why? Because
> > as soon as somebo
On Tue, Jul 4, 2017 at 10:22 AM, Michal Hocko wrote:
>
> Well, I've been thinking about this some more and the more I think about
> it the less I am convinced we should try to be clever here. Why? Because
> as soon as somebody tries to manage stacks explicitly you cannot simply
> assume anything a
On Tue 04-07-17 17:51:40, Willy Tarreau wrote:
> On Tue, Jul 04, 2017 at 12:36:11PM +0100, Ben Hutchings wrote:
> > > If anywhing this would require to have a loop over all PROT_NONE
> > > mappings to not hit into other weird usecases.
> >
> > That's what I was thinking of. Tried the following pa
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 */
> + /*
> + * Enforce stack_guard_gap, but allow VM_NONE mappi
On Tue, Jul 04, 2017 at 05:27:55PM +0100, John Haxby wrote:
> Alas, the people who could confirm this for me are getting ready to
> watch fireworks and generally have a good time.
Let's hope the fireworks is controlled by Java with on up-to-date
kernel so that they can quickly get back to work :-)
On 04/07/17 17:18, Linus Torvalds wrote:
> Also, separately, John Haxby kind of implied that the LibreOffice
> regression on i386 is already fixed by commit f4cb767d76cf ("mm: fix
> new crash in unmapped_area_topdown()").
I'm not certain. We had two distinct problems that were avoided by
Hugh's
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 sane to me.
I'm going to ignore it in this thread, and assume that it gets sent
On Tue, Jul 04, 2017 at 12:36:11PM +0100, Ben Hutchings wrote:
> > If anywhing this would require to have a loop over all PROT_NONE
> > mappings to not hit into other weird usecases.
>
> That's what I was thinking of. Tried the following patch:
(...)
> - next = vma->vm_next;
> + /*
> +
On Tue 04-07-17 14:19:00, Ximin Luo wrote:
[...]
> I've written up an explanation of what happens in the Rust case here:
>
> https://github.com/rust-lang/rust/issues/43052
The most important part is
https://github.com/rust-lang/rust/blob/master/src/libstd/sys/unix/thread.rs#L248
// Rello
Michal Hocko:
> On Tue 04-07-17 13:21:02, Ben Hutchings wrote:
>> On Tue, 2017-07-04 at 14:00 +0200, Michal Hocko wrote:
>>> On Tue 04-07-17 12:36:11, Ben Hutchings wrote:
On Tue, 2017-07-04 at 12:42 +0200, Michal Hocko wrote:
> On Tue 04-07-17 11:47:28, Willy Tarreau wrote:
>> On Tue,
On Tue 04-07-17 13:21:02, Ben Hutchings wrote:
> On Tue, 2017-07-04 at 14:00 +0200, Michal Hocko wrote:
> > On Tue 04-07-17 12:36:11, Ben Hutchings wrote:
> > > On Tue, 2017-07-04 at 12:42 +0200, Michal Hocko wrote:
> > > > On Tue 04-07-17 11:47:28, Willy Tarreau wrote:
> > > > > On Tue, Jul 04, 20
On 04/07/17 00:55, Ben Hutchings wrote:
> Unfortunately these regressions have not been completely fixed by
> switching to Hugh's fix.
>
> Firstly, some Rust programs are crashing on ppc64el with 64 KiB pages.
> Apparently Rust maps its own guard page at the lower limit of the stack
> (determined
On Tue, 2017-07-04 at 14:00 +0200, Michal Hocko wrote:
> On Tue 04-07-17 12:36:11, Ben Hutchings wrote:
> > On Tue, 2017-07-04 at 12:42 +0200, Michal Hocko wrote:
> > > On Tue 04-07-17 11:47:28, Willy Tarreau wrote:
> > > > On Tue, Jul 04, 2017 at 11:35:38AM +0200, Michal Hocko wrote:
> >
> > [...
On Tue 04-07-17 13:59:59, Michal Hocko wrote:
> On Tue 04-07-17 12:36:11, Ben Hutchings wrote:
> > On Tue, 2017-07-04 at 12:42 +0200, Michal Hocko wrote:
> > > On Tue 04-07-17 11:47:28, Willy Tarreau wrote:
> > > > On Tue, Jul 04, 2017 at 11:35:38AM +0200, Michal Hocko wrote:
> > [...]
> > > > But
On Tue 04-07-17 12:36:11, Ben Hutchings wrote:
> On Tue, 2017-07-04 at 12:42 +0200, Michal Hocko wrote:
> > On Tue 04-07-17 11:47:28, Willy Tarreau wrote:
> > > On Tue, Jul 04, 2017 at 11:35:38AM +0200, Michal Hocko wrote:
> [...]
> > > But wouldn't this completely disable the check in case such a
On Tue, 2017-07-04 at 12:42 +0200, Michal Hocko wrote:
> On Tue 04-07-17 11:47:28, Willy Tarreau wrote:
> > On Tue, Jul 04, 2017 at 11:35:38AM +0200, Michal Hocko wrote:
[...]
> > But wouldn't this completely disable the check in case such a guard page
> > is installed, and possibly continue to all
On Tue 04-07-17 12:46:52, Michal Hocko wrote:
[...]
> Tested with the attached program.
Err, attached now for real.
--
Michal Hocko
SUSE Labs
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define PAGE_SIZE sysconf(_SC_PAGESIZE)
#define PAGE_M
On Tue 04-07-17 11:35:38, Michal Hocko wrote:
> On Tue 04-07-17 10:41:22, Michal Hocko wrote:
> > On Mon 03-07-17 17:05:27, Linus Torvalds wrote:
> > > On Mon, Jul 3, 2017 at 4:55 PM, Ben Hutchings
> > > wrote:
> > > >
> > > > Firstly, some Rust programs are crashing on ppc64el with 64 KiB pages.
On Tue 04-07-17 11:47:28, Willy Tarreau wrote:
> On Tue, Jul 04, 2017 at 11:35:38AM +0200, Michal Hocko wrote:
> > On Tue 04-07-17 10:41:22, Michal Hocko wrote:
> > > On Mon 03-07-17 17:05:27, Linus Torvalds wrote:
> > > > On Mon, Jul 3, 2017 at 4:55 PM, Ben Hutchings
> > > > wrote:
> > > > >
> >
On Tue, Jul 04, 2017 at 11:35:38AM +0200, Michal Hocko wrote:
> On Tue 04-07-17 10:41:22, Michal Hocko wrote:
> > On Mon 03-07-17 17:05:27, Linus Torvalds wrote:
> > > On Mon, Jul 3, 2017 at 4:55 PM, Ben Hutchings
> > > wrote:
> > > >
> > > > Firstly, some Rust programs are crashing on ppc64el wi
On Tue 04-07-17 10:41:22, Michal Hocko wrote:
> On Mon 03-07-17 17:05:27, Linus Torvalds wrote:
> > On Mon, Jul 3, 2017 at 4:55 PM, Ben Hutchings wrote:
> > >
> > > Firstly, some Rust programs are crashing on ppc64el with 64 KiB pages.
> > > Apparently Rust maps its own guard page at the lower lim
On Mon 03-07-17 17:05:27, Linus Torvalds wrote:
> On Mon, Jul 3, 2017 at 4:55 PM, Ben Hutchings wrote:
> >
> > Firstly, some Rust programs are crashing on ppc64el with 64 KiB pages.
> > Apparently Rust maps its own guard page at the lower limit of the stack
> > (determined using pthread_getattr_np
On Mon, Jul 3, 2017 at 4:55 PM, Ben Hutchings wrote:
> On Wed, 2017-06-21 at 11:47 +0100, Ben Hutchings wrote:
>> On Wed, 2017-06-21 at 11:24 +0200, Michal Hocko wrote:
>> > On Wed 21-06-17 02:38:21, Ben Hutchings wrote:
>> > > On Mon, 2017-06-19 at 16:23 +0200, Willy Tarreau wrote:
>> > > > On Mo
On Mon, Jul 3, 2017 at 4:55 PM, Ben Hutchings wrote:
>
> Firstly, some Rust programs are crashing on ppc64el with 64 KiB pages.
> Apparently Rust maps its own guard page at the lower limit of the stack
> (determined using pthread_getattr_np() and pthread_attr_getstack()). I
> don't think this eve
On Wed, 2017-06-21 at 11:47 +0100, Ben Hutchings wrote:
> On Wed, 2017-06-21 at 11:24 +0200, Michal Hocko wrote:
> > On Wed 21-06-17 02:38:21, Ben Hutchings wrote:
> > > On Mon, 2017-06-19 at 16:23 +0200, Willy Tarreau wrote:
> > > > On Mon, Jun 19, 2017 at 08:44:24PM +0800, Linus Torvalds wrote:
>
On Sat, 2017-06-24 at 02:11 -0700, Hugh Dickins wrote:
> On Thu, 22 Jun 2017, Hugh Dickins wrote:
> > On Thu, 22 Jun 2017, Ben Hutchings wrote:
> >
> > > Here's my attempt at a backport to 3.2. This is only tested on
> > > x86_64 and I think I should introduce local variables for
> > > vma_start_
On Thu, 22 Jun 2017, Hugh Dickins wrote:
> On Thu, 22 Jun 2017, Ben Hutchings wrote:
>
> > Here's my attempt at a backport to 3.2. This is only tested on
> > x86_64 and I think I should introduce local variables for
> > vma_start_gap() in a few places. I had to cherry-pick commit
> > 09884964335
On Thu, Jun 22, 2017 at 8:10 PM, Andy Lutomirski wrote:
>
> Has anyone checked how grsecurity deals with this? I think they have
> a large stack guard gap.
Don't bother with grsecurity.
Their approach has always been "we don't care if we break anything,
we'll just claim it's because we're extra
On Thu, 22 Jun 2017, Ben Hutchings wrote:
> Here's my attempt at a backport to 3.2. This is only tested on
> x86_64 and I think I should introduce local variables for
> vma_start_gap() in a few places. I had to cherry-pick commit
> 09884964335e "mm: do not grow the stack vma just because of an o
On Thu, Jun 22, 2017 at 7:34 AM, Willy Tarreau wrote:
> On Thu, Jun 22, 2017 at 03:14:00PM +0100, Ben Hutchings wrote:
>> On Thu, 2017-06-22 at 15:59 +0200, Willy Tarreau wrote:
>> > but I think Ben is currently looking
>> > for feedback on the validity of his backport which was a difficult
>> > t
On 22.06.2017 16:14, Ben Hutchings wrote:
> On Thu, 2017-06-22 at 15:59 +0200, Willy Tarreau wrote:
>>> -- Allow stack to grow up to address space limit
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
>>> commit/?id=bd726c90b6b8ce87602208701b208a208e6d5600
>>
>> This one cle
On Thu, Jun 22, 2017 at 03:14:00PM +0100, Ben Hutchings wrote:
> On Thu, 2017-06-22 at 15:59 +0200, Willy Tarreau wrote:
> > but I think Ben is currently looking
> > for feedback on the validity of his backport which was a difficult
> > task.
>
> Right.
Ben, barring more feedback, I think your sh
On Thu, 2017-06-22 at 15:59 +0200, Willy Tarreau wrote:
> Hi,
>
> On Thu, Jun 22, 2017 at 03:15:51PM +0200, Levente Polyak wrote:
> > Just a side note, but i think its worth mentioning to also have
> > look at
> > these fixup patches:
> >
> >
> > -- mm: fix new crash in unmapped_area_topdown()
>
Hi,
On Thu, Jun 22, 2017 at 03:15:51PM +0200, Levente Polyak wrote:
> Just a side note, but i think its worth mentioning to also have look at
> these fixup patches:
>
>
> -- mm: fix new crash in unmapped_area_topdown()
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?
binnqgCLRXfKN.bin
Description: PGP/MIME version identification
encrypted.asc
Description: OpenPGP encrypted message
On Thu, Jun 22, 2017 at 03:10:34PM +0200, Willy Tarreau wrote:
> On Thu, Jun 22, 2017 at 01:58:11PM +0100, Ben Hutchings wrote:
> > On Thu, 2017-06-22 at 14:46 +0200, Willy Tarreau wrote:
> > > On Thu, Jun 22, 2017 at 01:30:45PM +0100, Ben Hutchings wrote:
> > > > Here's my attempt at a backport to
On Thu, Jun 22, 2017 at 01:58:11PM +0100, Ben Hutchings wrote:
> On Thu, 2017-06-22 at 14:46 +0200, Willy Tarreau wrote:
> > On Thu, Jun 22, 2017 at 01:30:45PM +0100, Ben Hutchings wrote:
> > > Here's my attempt at a backport to 3.2. This is only tested on
> > > x86_64 and I think I should introdu
On Thu, 2017-06-22 at 14:46 +0200, Willy Tarreau wrote:
> On Thu, Jun 22, 2017 at 01:30:45PM +0100, Ben Hutchings wrote:
> > Here's my attempt at a backport to 3.2. This is only tested on
> > x86_64 and I think I should introduce local variables for
> > vma_start_gap() in a few places. I had to c
On Thu, Jun 22, 2017 at 01:30:45PM +0100, Ben Hutchings wrote:
> Here's my attempt at a backport to 3.2. This is only tested on
> x86_64 and I think I should introduce local variables for
> vma_start_gap() in a few places. I had to cherry-pick commit
> 09884964335e "mm: do not grow the stack vma
Here's my attempt at a backport to 3.2. This is only tested on
x86_64 and I think I should introduce local variables for
vma_start_gap() in a few places. I had to cherry-pick commit
09884964335e "mm: do not grow the stack vma just because of an overrun
on preceding vma" before this one (which was
90 matches
Mail list logo
