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

[Solar Designer]

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 to linux-distros, which is for handling of embargoed
issues only.  So please drop linux-distros from further CC's (I moved
linux-distros to Bcc on this reply, just so they know what happened).

If specific security issues are identified (such as with LibreOffice and
Java), then ideally those should be posted to oss-security as separate
reports.  I'd appreciate it if anyone takes care of that (regardless of
CVE worthiness).

In fact, I already mentioned this thread in:

http://www.openwall.com/lists/oss-security/2017/07/05/11

Thank you!

Alexander

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

[Solar Designer]

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 to linux-distros, which is for handling of embargoed
issues only.  So please drop linux-distros from further CC's (I moved
linux-distros to Bcc on this reply, just so they know what happened).

If specific security issues are identified (such as with LibreOffice and
Java), then ideally those should be posted to oss-security as separate
reports.  I'd appreciate it if anyone takes care of that (regardless of
CVE worthiness).

In fact, I already mentioned this thread in:

http://www.openwall.com/lists/oss-security/2017/07/05/11

Thank you!

Alexander

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

[kseifr...@redhat.com]

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

[kseifr...@redhat.com]

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

[John Haxby]

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 using pthread_getattr_np() and pthread_attr_getstack()).  I
> don't think this ever actually worked for the main thread stack, but it
> now also blocks expansion as the default stack size of 8 MiB is smaller
> than the stack gap of 16 MiB.  Would it make sense to skip over
> PROT_NONE mappings when checking whether it's safe to expand?
> 
> Secondly, LibreOffice is crashing on i386 when running components
> implemented in Java.  I don't have a diagnosis for this yet.

We found that we needed f4cb767d76cf ("mm: fix new crash in
unmapped_area_topdown()")   Apologies if you've already covered that.

This may be needed in addition to the other patch you proposed.

jch

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

[John Haxby]

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 using pthread_getattr_np() and pthread_attr_getstack()).  I
> don't think this ever actually worked for the main thread stack, but it
> now also blocks expansion as the default stack size of 8 MiB is smaller
> than the stack gap of 16 MiB.  Would it make sense to skip over
> PROT_NONE mappings when checking whether it's safe to expand?
> 
> Secondly, LibreOffice is crashing on i386 when running components
> implemented in Java.  I don't have a diagnosis for this yet.

We found that we needed f4cb767d76cf ("mm: fix new crash in
unmapped_area_topdown()")   Apologies if you've already covered that.

This may be needed in addition to the other patch you proposed.

jch

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

[Linus Torvalds]

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 secure".

The thing is a joke, and they are clowns. When they started talking
about people taking advantage of them, I stopped trying to be polite
about their bullshit.

Their patches are pure garbage.

  Linus

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

[Linus Torvalds]

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 secure".

The thing is a joke, and they are clowns. When they started talking
about people taking advantage of them, I stopped trying to be polite
about their bullshit.

Their patches are pure garbage.

  Linus

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

[Andy Lutomirski]

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
>> > task.
>>
>> Right.
>
> Ben, barring more feedback, I think your should put your patch to your
> stable queue so that Guenter can run his build+boot tests. They managed
> to spot a few issues in my patches and that will make you more confident
> regarding the whole architectures coverage.
>

Has anyone checked how grsecurity deals with this?  I think they have
a large stack guard gap.

--Andy

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

[Andy Lutomirski]

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
>> > task.
>>
>> Right.
>
> Ben, barring more feedback, I think your should put your patch to your
> stable queue so that Guenter can run his build+boot tests. They managed
> to spot a few issues in my patches and that will make you more confident
> regarding the whole architectures coverage.
>

Has anyone checked how grsecurity deals with this?  I think they have
a large stack guard gap.

--Andy

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

[Helge Deller]

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 cleanly applies after, but I think Ben is currently looking
>> for feedback on the validity of his backport which was a difficult
>> task.
> 
> Right.

Ben,
I might be able to give it a try, but I'm not sure if I'm able to boot
that kernel on my parisc box. Kernel 3.9 was basically the first one
which was run basically stable on parisc, but since then we had
some ABI changes in userspace (reduced SIGRTMIN, made
EWOULDBLOCK == EAGAIN) which might prevent me to boot that
kernel with current glibc.
Anyway, can you point me to your patches ?

Helge

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

[Helge Deller]

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 cleanly applies after, but I think Ben is currently looking
>> for feedback on the validity of his backport which was a difficult
>> task.
> 
> Right.

Ben,
I might be able to give it a try, but I'm not sure if I'm able to boot
that kernel on my parisc box. Kernel 3.9 was basically the first one
which was run basically stable on parisc, but since then we had
some ABI changes in userspace (reduced SIGRTMIN, made
EWOULDBLOCK == EAGAIN) which might prevent me to boot that
kernel with current glibc.
Anyway, can you point me to your patches ?

Helge

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

[Willy Tarreau]

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 should put your patch to your
stable queue so that Guenter can run his build+boot tests. They managed
to spot a few issues in my patches and that will make you more confident
regarding the whole architectures coverage.

Just my 2c,
Willy

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

[Willy Tarreau]

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 should put your patch to your
stable queue so that Guenter can run his build+boot tests. They managed
to spot a few issues in my patches and that will make you more confident
regarding the whole architectures coverage.

Just my 2c,
Willy

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

[Ben Hutchings]

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()
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
> > commit/?id=f4cb767d76cf7ee72f97dd76f6cfa6c76a5edc89
> 
> As I mentionned in another mail (this thread starts to be huge), this
> one seems to have already been included in Ben's backport.

That code was completely replaced due to the lack of an rbtree for gaps
in 3.2, so the fix was not needed.

> > -- 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 cleanly applies after, but I think Ben is currently looking
> for feedback on the validity of his backport which was a difficult
> task.

Right.

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.



signature.asc
Description: This is a digitally signed message part

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

[Ben Hutchings]

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()
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
> > commit/?id=f4cb767d76cf7ee72f97dd76f6cfa6c76a5edc89
> 
> As I mentionned in another mail (this thread starts to be huge), this
> one seems to have already been included in Ben's backport.

That code was completely replaced due to the lack of an rbtree for gaps
in 3.2, so the fix was not needed.

> > -- 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 cleanly applies after, but I think Ben is currently looking
> for feedback on the validity of his backport which was a difficult
> task.

Right.

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.



signature.asc
Description: This is a digitally signed message part

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

[Willy Tarreau]

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/?id=f4cb767d76cf7ee72f97dd76f6cfa6c76a5edc89

As I mentionned in another mail (this thread starts to be huge), this
one seems to have already been included in Ben's backport.

> -- 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 cleanly applies after, but I think Ben is currently looking
for feedback on the validity of his backport which was a difficult task.

Regards,
Willy

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

[Willy Tarreau]

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/?id=f4cb767d76cf7ee72f97dd76f6cfa6c76a5edc89

As I mentionned in another mail (this thread starts to be huge), this
one seems to have already been included in Ben's backport.

> -- 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 cleanly applies after, but I think Ben is currently looking
for feedback on the validity of his backport which was a difficult task.

Regards,
Willy

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

[Levente Polyak]

binnqgCLRXfKN.bin
Description: PGP/MIME version identification


encrypted.asc
Description: OpenPGP encrypted message

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

[Levente Polyak]

binnqgCLRXfKN.bin
Description: PGP/MIME version identification


encrypted.asc
Description: OpenPGP encrypted message