https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #27 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kib
Date: Tue Sep 10 09:57:25 UTC 2019
New revision: 352133
URL: https://svnweb.freebsd.org/changeset/base/352133
Log:
MFC r351774:
Add stackgap con
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #26 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kib
Date: Tue Sep 10 07:29:23 UTC 2019
New revision: 352125
URL: https://svnweb.freebsd.org/changeset/base/352125
Log:
MFC r351773:
Add procctl(PROC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #25 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kib
Date: Tue Sep 10 06:47:40 UTC 2019
New revision: 352118
URL: https://svnweb.freebsd.org/changeset/base/352118
Log:
MFC r351774:
Add stackgap con
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #24 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kib
Date: Tue Sep 10 06:45:46 UTC 2019
New revision: 352117
URL: https://svnweb.freebsd.org/changeset/base/352117
Log:
MFC r351773:
Add procctl(PROC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #23 from Greg Lewis ---
Thanks, that is good to hear.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #22 from Konstantin Belousov ---
(In reply to Greg Lewis from comment #21)
Yes, it should be in stable/12 before 12.1.
I think it will be merged to 11 as well, unless it appeared to be too
complicated.
--
You are receiving th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #21 from Greg Lewis ---
Thanks for the update Konstantin. Can I take it from the MFC timeline that you
are intending to merge this back to 12-STABLE prior to the branch for 12.1?
--
You are receiving this mail because:
You ar
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #20 from Konstantin Belousov ---
After r351773, you can add the following fragment at the beginning of the jvm
initialization. It is safe to ignore errors from procctl(2), which means that
the kernel is old and stack overflow d
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #19 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kib
Date: Tue Sep 3 18:58:48 UTC 2019
New revision: 351774
URL: https://svnweb.freebsd.org/changeset/base/351774
Log:
Add stackgap control mode to pr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #18 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kib
Date: Tue Sep 3 18:56:27 UTC 2019
New revision: 351773
URL: https://svnweb.freebsd.org/changeset/base/351773
Log:
Add procctl(PROC_STACKGAP_CTL)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #17 from Greg Lewis ---
I got a VM set up with a recent -CURRENT, applied the patches from the review
and rebuilt world.
I can confirm that after that I can run
proccontrol -m stackgap -s disable java -cp . InfiniteRecursion
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #16 from Konstantin Belousov ---
(In reply to Greg Lewis from comment #15)
To check that PROC_STACKGAP_CTL helps, please build kernel and world (or just
usr.sbin/proccontrol) with D21352 applied. Then you can run unmodified jav
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #15 from Greg Lewis ---
Hi Konstantin,
It looks like you have been working on the procctl approach based on
https://reviews.freebsd.org/D21352. Thanks for doing that! A couple of
questions/comments though.
Can we help test t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #14 from Shawn Webb ---
(In reply to Kurt Miller from comment #13)
> The authors of the Stack Clash advisory indicate a 4096 byte guard region is
> not difficult to jump over and avoid. Their recommendation is a 1MB guard
> re
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #13 from Kurt Miller ---
(In reply to Shawn Webb from comment #12)
The authors of the Stack Clash advisory indicate a 4096 byte guard region is
not difficult to jump over and avoid. Their recommendation is a 1MB guard
region. R
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
Shawn Webb changed:
What|Removed |Added
CC||shawn.w...@hardenedbsd.org
--- Commen
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #11 from Kurt Miller ---
(In reply to Kurt Miller from comment #10)
Sorry, typo in previous comment. It should have read "...setting
security.bsd.stack_guard_page to 513 will cause all future pthread_create(2)
calls to fail..."
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #10 from Kurt Miller ---
(In reply to Konstantin Belousov from comment #8)
Thank you for writing this. However, it doesn't address the interaction between
kernel placed guard pages and pthreads. Consider for example setting
sec
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #9 from Kurt Miller ---
(In reply to Konstantin Belousov from comment #7)
Answering your questions:
Attempting execute code on the stack I believe with raise a SIGSEGV.
The JVM uses pthread stacks.
Currently the jvm does an m
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #8 from Konstantin Belousov ---
I also wrote the promised procctl(PROC_STACKGAP_CTL), see
https://reviews.freebsd.org/D21352. But I do not think that it would alone
help with the JVM use of guards. It might be needed in additi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #7 from Konstantin Belousov ---
(In reply to Greg Lewis from comment #6)
First, I am not sure what you mean by 'ther reasons a SIGSEGV could occur in
the normal stack region (e.g. a buffer overflow)'. If the region is mapped rw
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #6 from Greg Lewis ---
Hi Konstantin,
I think my explanation hasn't been clear enough. So let me try and include a
few more links and some diagrams.
Here is a diagram for what the Java thread stack looks like from
https://git
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #5 from Konstantin Belousov ---
(In reply to Greg Lewis from comment #3)
I am not proposing to interpret any SIGSEGV as a stack overflow. I propose to
consider a SIGSEGV as the stack overflow if it occured in the range of
[guar
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #4 from Kurt Miller ---
Yes, that's the root of the problem. The JVM needs to be able to
deterministically manage its own guard pages independently from both the kernel
placed ones and the pthread placed ones. Where 'manage' mea
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #3 from Greg Lewis ---
Thanks for the response Konstantin!
I can see a couple of problems with that approach.
The biggest problem is that not all SIGSEGV should be interpreted as a stack
overflow. With the possibility of what
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #2 from Konstantin Belousov ---
(In reply to Greg Lewis from comment #0)
Can you switch from checking that the faulted address belong strongly to the
guard pages created explicitly, to the mere fact that the faulted address fall
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
Kurt Miller changed:
What|Removed |Added
CC||k...@intricatesoftware.com
--- Comme
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
Bug ID: 239894
Summary: security.bsd.stack_guard_page default causes Java to
crash
Product: Base System
Version: 12.0-RELEASE
Hardware: Any
OS: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
Greg Lewis changed:
What|Removed |Added
Severity|Affects Only Me |Affects Many People
--
You are recei
29 matches
Mail list logo
