Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1680619 > unrolled thread
| Started by | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| First post | 2017-07-04 02:00 +0200 |
| Last post | 2017-07-04 14:30 +0200 |
| Articles | 15 on this page of 75 — 12 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH] mm: larger stack guard gap, between vmas Ben Hutchings <ben@decadent.org.uk> - 2017-07-04 02:00 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-04 02:10 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Michal Hocko <mhocko@kernel.org> - 2017-07-04 10:50 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Michal Hocko <mhocko@kernel.org> - 2017-07-04 11:40 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Willy Tarreau <w@1wt.eu> - 2017-07-04 11:50 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Michal Hocko <mhocko@kernel.org> - 2017-07-04 12:50 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Ben Hutchings <ben@decadent.org.uk> - 2017-07-04 13:40 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Michal Hocko <mhocko@kernel.org> - 2017-07-04 14:10 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Michal Hocko <mhocko@kernel.org> - 2017-07-04 14:20 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Ben Hutchings <ben@decadent.org.uk> - 2017-07-04 14:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Michal Hocko <mhocko@kernel.org> - 2017-07-04 14:40 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Ximin Luo <infinity0@debian.org> - 2017-07-04 16:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Michal Hocko <mhocko@kernel.org> - 2017-07-04 16:50 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Willy Tarreau <w@1wt.eu> - 2017-07-04 18:00 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Michal Hocko <mhocko@kernel.org> - 2017-07-04 19:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-04 20:40 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-04 20:50 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Willy Tarreau <w@1wt.eu> - 2017-07-04 21:10 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Willy Tarreau <w@1wt.eu> - 2017-07-04 20:50 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-04 18:20 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas John Haxby <john.haxby@oracle.com> - 2017-07-04 18:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Willy Tarreau <w@1wt.eu> - 2017-07-04 19:10 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Ben Hutchings <ben@decadent.org.uk> - 2017-07-05 14:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Willy Tarreau <w@1wt.eu> - 2017-07-04 19:20 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Ben Hutchings <ben@decadent.org.uk> - 2017-07-05 14:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Ben Hutchings <ben@decadent.org.uk> - 2017-07-05 01:10 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-05 01:40 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Michal Hocko <mhocko@kernel.org> - 2017-07-05 08:40 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Willy Tarreau <w@1wt.eu> - 2017-07-05 10:20 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Michal Hocko <mhocko@kernel.org> - 2017-07-05 10:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Willy Tarreau <w@1wt.eu> - 2017-07-05 11:20 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Ben Hutchings <ben@decadent.org.uk> - 2017-07-05 14:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Willy Tarreau <w@1wt.eu> - 2017-07-05 16:00 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Michal Hocko <mhocko@kernel.org> - 2017-07-05 16:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-05 18:10 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Michal Hocko <mhocko@kernel.org> - 2017-07-06 09:40 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Ben Hutchings <ben@decadent.org.uk> - 2017-07-05 14:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Michal Hocko <mhocko@kernel.org> - 2017-07-05 16:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Ben Hutchings <ben@decadent.org.uk> - 2017-07-05 17:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Michal Hocko <mhocko@kernel.org> - 2017-07-05 18:10 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Ben Hutchings <ben@decadent.org.uk> - 2017-07-05 19:00 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Michal Hocko <mhocko@kernel.org> - 2017-07-05 19:10 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Ben Hutchings <ben@decadent.org.uk> - 2017-07-05 19:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-05 19:20 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Ben Hutchings <ben@decadent.org.uk> - 2017-07-06 01:40 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-06 02:00 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Willy Tarreau <w@1wt.eu> - 2017-07-06 10:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Willy Tarreau <w@1wt.eu> - 2017-07-06 12:20 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Andy Lutomirski <luto@kernel.org> - 2017-07-05 18:20 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-05 18:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Andy Lutomirski <luto@kernel.org> - 2017-07-05 19:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Ben Hutchings <ben@decadent.org.uk> - 2017-07-05 21:40 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Willy Tarreau <w@1wt.eu> - 2017-07-05 22:50 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Andy Lutomirski <luto@amacapital.net> - 2017-07-05 23:00 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Ben Hutchings <ben@decadent.org.uk> - 2017-07-06 02:00 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Andy Lutomirski <luto@kernel.org> - 2017-07-06 02:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Kees Cook <keescook@chromium.org> - 2017-07-06 02:00 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-06 02:00 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Andy Lutomirski <luto@kernel.org> - 2017-07-06 02:40 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-06 02:50 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Andy Lutomirski <luto@kernel.org> - 2017-07-06 02:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Kees Cook <keescook@chromium.org> - 2017-07-06 04:50 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Willy Tarreau <w@1wt.eu> - 2017-07-06 07:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Kevin Easton <kevin@guarana.org> - 2017-07-06 07:40 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-05 18:20 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Willy Tarreau <w@1wt.eu> - 2017-07-05 21:10 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Willy Tarreau <w@1wt.eu> - 2017-07-05 21:20 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-05 21:30 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-05 21:20 +0200
Re: [vs-plain] Re: [PATCH] mm: larger stack guard gap, between vmas "kseifried@redhat.com" <kseifried@redhat.com> - 2017-07-05 03:20 +0200
Re: [vs-plain] Re: [PATCH] mm: larger stack guard gap, between vmas Solar Designer <solar@openwall.com> - 2017-07-05 16:20 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Michal Hocko <mhocko@kernel.org> - 2017-07-04 12:50 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Michal Hocko <mhocko@kernel.org> - 2017-07-04 13:00 +0200
Re: [PATCH] mm: larger stack guard gap, between vmas Andy Lutomirski <luto@kernel.org> - 2017-07-04 02:30 +0200
Re: [vs-plain] Re: [PATCH] mm: larger stack guard gap, between vmas John Haxby <john.haxby@oracle.com> - 2017-07-04 14:30 +0200
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Andy Lutomirski <luto@kernel.org> |
|---|---|
| Date | 2017-07-06 02:30 +0200 |
| Message-ID | <u02Qa-5ct-9@gated-at.bofh.it> |
| In reply to | #1681955 |
On Wed, Jul 5, 2017 at 4:50 PM, Kees Cook <keescook@chromium.org> wrote: > On Wed, Jul 5, 2017 at 10:23 AM, Andy Lutomirski <luto@kernel.org> 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 is allowed to break ABI. My security hat >> is normally pretty hard-line, but I think it may be time to call BS. >> >> Imagine if Kees had sent some symlink hardening patch that was >> default-on and broke a stock distro. Or if I had sent a vsyscall >> hardening patch that broke real code. It would get reverted right >> away, probably along with a diatribe about how we should have known >> better. I think this stack gap stuff is the same thing. It's not a >> security fix -- it's a hardening patch. >> >> 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 as hardening. I would suggest the following approach: >> >> - The stack gap is one page, just like it's been for years. >> - 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 that, if you deliberately place a mapping under the >> stack, you know what you're doing. If you're like LibreOffice and do >> something daft and are thus exploitable, you're on your own. >> - As a hardening measure, don't let mmap without MAP_FIXED position >> something within 64k or whatever of the bottom of the stack unless a >> MAP_FIXED mapping is between them. >> >> And that's all. It's not like a 64k gap actually fixes these bugs for >> real -- it just makes them harder to exploit. >> >> [1] The code that GCC generates for char buf[bug number] and alloca() >> is flat-out wrong. Everyone who's ever thought about it all all knows >> it and has known about it for years, but no one cared to fix it. > > 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 rlimits can have lead > to the nasty memory layout side-effects. That would fall into the > "hardening" bucket as well. And if it turns out there is some set*id > binary out there that can't run with "only", e.g., 128MB of stack, we > can make it configurable... Yes. 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 privilege and reset to those limits when running something setuid. But a better approach might be to have some sysctls that say what the rlimits become when doing setuid. We need per-user-ns sysctls for stuff like this, and we don't really have them... --Andy
[toc] | [prev] | [next] | [standalone]
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Date | 2017-07-06 04:50 +0200 |
| Message-ID | <u051E-6B8-5@gated-at.bofh.it> |
| In reply to | #1681970 |
On Wed, Jul 5, 2017 at 5:19 PM, Andy Lutomirski <luto@kernel.org> wrote: > On Wed, Jul 5, 2017 at 4:50 PM, Kees Cook <keescook@chromium.org> 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 rlimits can have lead >> to the nasty memory layout side-effects. That would fall into the >> "hardening" bucket as well. And if it turns out there is some set*id >> binary out there that can't run with "only", e.g., 128MB of stack, we >> can make it configurable... > > Yes. 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 privilege and reset to those limits when running > something setuid. But a better approach might be to have some sysctls > that say what the rlimits become when doing setuid. > > We need per-user-ns sysctls for stuff like this, and we don't really > have them... In userspace, the way that sensible rlimit defaults were selected by PAM when building an initial environment is to just examine the rlimits of init. Maybe we could just do the same thing here, which gives us some level of namespace control. -Kees -- Kees Cook Pixel Security
[toc] | [prev] | [next] | [standalone]
| From | Willy Tarreau <w@1wt.eu> |
|---|---|
| Date | 2017-07-06 07:30 +0200 |
| Message-ID | <u07wt-8qx-5@gated-at.bofh.it> |
| In reply to | #1681970 |
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 privilege and reset to those limits when running > something setuid. But a better approach might be to have some sysctls > that say what the rlimits become when doing setuid. *Some* rlimits are useful and needed for the user as you mentionned. RLIMIT_CORE definitely is one of them, especially for debugging, when combined with suid_dumpable. Some others like RLIMIT_STACK should probably never be configurable at all and cause trouble. Probably that simply having a sysctl to set this one for setuid programs and ignore the current limit would be enough. We could even imagine another one to set the stack guard gap for setuid programs (this would also limit the impacts of having a large gap for everyone). > We need per-user-ns sysctls for stuff like this, and we don't really > have them... I don't think we need to be this fine-grained. min_mmap_addr is global, is used to address very similar issues and nobody seems to complain. Willy
[toc] | [prev] | [next] | [standalone]
| From | Kevin Easton <kevin@guarana.org> |
|---|---|
| Date | 2017-07-06 07:40 +0200 |
| Message-ID | <u07G9-8uO-3@gated-at.bofh.it> |
| In reply to | #1681559 |
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 <ben@decadent.org.uk>
> > > wrote:
> > > >
> > > > We have:
> > > >
> > > > bottom = 0xff803fff
> > > > sp =?????0xffffb178
> > > >
> > > > The relevant mappings are:
> > > >
> > > > ff7fc000-ff7fd000 rwxp 00000000 00:00 0
> > > > fffdd000-ffffe000 rw-p 00000000 00:00
> > > > 0??????????????????????????????????[stack]
> > >
> > > Ugh. So that stack is actually 8MB in size, but the alloca() is about
> > > to use up almost all of it, and there's only about 28kB left between
> > > "bottom" and that 'rwx' mapping.
> > >
> > > Still, that rwx mapping is interesting: it is a single page, and it
> > > really is almost exactly 8MB below the stack.
> > >
> > > In fact, the top of stack (at 0xffffe000) is *exactly* 8MB+4kB from
> > > the top of that odd one-page allocation (0xff7fd000).
> > >
> > > 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:
> > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/os/linux/vm/os_linux.cpp#l4852
> > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/os_cpu/linux_x86/vm/os_linux_x86.cpp#l881
>
> 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 afraid the only way forward is to
> allow per process stack gap and run this particular program to have a
> smaller gap. We basically have two ways. Either /proc/<pid>/$file or
> a prctl inherited on exec. The later is a smaller code. What do you
> think?
On the plus side, the code in that page (a single RET) is only executed
once when the workaround function is called. Notice that 'codebuf'
is never even returned out of that function.
The only reason they even leave that page mapped is to stop the exec
shield limit from being lowered on them again.
- Kevin
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2017-07-05 18:20 +0200 |
| Message-ID | <tZVbY-77-5@gated-at.bofh.it> |
| In reply to | #1681504 |
On Wed, Jul 5, 2017 at 5:19 AM, Ben Hutchings <ben@decadent.org.uk> 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:
> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/os/linux/vm/os_linux.cpp#l4852
> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/os_cpu/linux_x86/vm/os_linux_x86.cpp#l881
Thanks, good work.
Well, good work on *your* part. I will try very hard to refrain from
commenting too much on the f*cking stinking pile of sh*t that was
exec-shield.
But yes, I don't think we can sanely recognize this. The code clearly
very intentionally does that mapping under the stack, and it's very
intentionally not PROT_NONE, since it's meant to be both writable and
executable.
As I said earlier (and I see Michal Hocko suggested the same - sudden
email flurry going on here), I think we need to basically allow people
to set the stack gap per-process to something low.
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 support 32-bit (which is
apparently a shrinking number) can maybe hack the libreoffice launch
scripts up?
Linus
[toc] | [prev] | [next] | [standalone]
| From | Willy Tarreau <w@1wt.eu> |
|---|---|
| Date | 2017-07-05 21:10 +0200 |
| Message-ID | <tZXQu-1WT-15@gated-at.bofh.it> |
| In reply to | #1681633 |
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 support 32-bit (which is > apparently a shrinking number) can maybe hack the libreoffice launch > scripts up? 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 that used to work (4k or 64k, I don't remember) and try again ? It would quickly report all these "special" programs for end-user distros, without leaving too much room for attacks due to the warning making it pretty obvious what's going on. I just don't know how to place this stack gap per process but since this was already discussed for prctl I think it's doable. Willy
[toc] | [prev] | [next] | [standalone]
| From | Willy Tarreau <w@1wt.eu> |
|---|---|
| Date | 2017-07-05 21:20 +0200 |
| Message-ID | <tZY09-21z-9@gated-at.bofh.it> |
| In reply to | #1681716 |
On Wed, Jul 05, 2017 at 12:17:20PM -0700, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 11:59 AM, Willy Tarreau <w@1wt.eu> 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 that used to work (4k or 64k, I don't remember) > > and try again ? > > It used to be just 4k. > > .. and I think that might be a valid way to find these things, but > would it be safer? It basically disables the new stack gap entirely > apart from the warning. 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. Willy
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2017-07-05 21:30 +0200 |
| Message-ID | <tZY9Q-273-19@gated-at.bofh.it> |
| In reply to | #1681722 |
On Wed, Jul 5, 2017 at 12:18 PM, Willy Tarreau <w@1wt.eu> 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 simpler
overall, and would help find other potential problem spots.
*Hopefully* it was just that Rust thing and the nasty Java exec-shield
workaround, but yeah, those might just be the first ones that have
been found so far.
Linus
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2017-07-05 21:20 +0200 |
| Message-ID | <tZY09-21z-11@gated-at.bofh.it> |
| In reply to | #1681716 |
On Wed, Jul 5, 2017 at 11:59 AM, Willy Tarreau <w@1wt.eu> 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 that used to work (4k or 64k, I don't remember)
> and try again ?
It used to be just 4k.
.. and I think that might be a valid way to find these things, but
would it be safer? It basically disables the new stack gap entirely
apart from the warning.
And maybe that's ok and distros prefer that?
Linus
[toc] | [prev] | [next] | [standalone]
| From | "kseifried@redhat.com" <kseifried@redhat.com> |
|---|---|
| Date | 2017-07-05 03:20 +0200 |
| Subject | Re: [vs-plain] Re: [PATCH] mm: larger stack guard gap, between vmas |
| Message-ID | <tZH8Z-7MS-3@gated-at.bofh.it> |
| In reply to | #1681210 |
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: secalert@redhat.com
[toc] | [prev] | [next] | [standalone]
| From | Solar Designer <solar@openwall.com> |
|---|---|
| Date | 2017-07-05 16:20 +0200 |
| Subject | Re: [vs-plain] Re: [PATCH] mm: larger stack guard gap, between vmas |
| Message-ID | <tZTjR-7oP-13@gated-at.bofh.it> |
| In reply to | #1681238 |
Hi all, On Tue, Jul 04, 2017 at 07:16:06PM -0600, kseifried@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
[toc] | [prev] | [next] | [standalone]
| From | Michal Hocko <mhocko@kernel.org> |
|---|---|
| Date | 2017-07-04 12:50 +0200 |
| Message-ID | <tZtz4-76W-27@gated-at.bofh.it> |
| In reply to | #1680806 |
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 <ben@decadent.org.uk> 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 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? > > > > This is what my workaround for the older patch was doing, actually. We > > have deployed that as a follow up fix on our older code bases. And this > > has fixed verious issues with Java which was doing the similar thing. > > Here is a forward port (on top of the current Linus tree) of my earlier > patch. I have dropped a note about java stack trace because this would > most likely be not the case with the Hugh's patch. The problem is the > same in principle though. Note I didn't get to test this properly yet > but it should be pretty much obvious. Tested with the attached program. root@test1:~# ./stack_crash Stack top:0x7fffcdb605ec mmap:0x7fffcc760000 address:0x7fffcc760ff8 aligned:0x7fffcc760000 mapped:[7fffcc760000,7fffcc761000] diff:-8 [...] so we faulted on the PROT_NONE while with #define MAPING_PROT PROT_READ root@test1:~# ./stack_crash Stack top:0x7ffe73dde6fc mmap:0x7ffe729de000 address:0x7ffe72adefd8 aligned:0x7ffe72ade000 mapped:[7ffe729de000,7ffe729df000] diff:1048536 [...] we failed 1MB ahead of the mapping. -- Michal Hocko SUSE Labs
[toc] | [prev] | [next] | [standalone]
| From | Michal Hocko <mhocko@kernel.org> |
|---|---|
| Date | 2017-07-04 13:00 +0200 |
| Message-ID | <tZtIL-7a9-31@gated-at.bofh.it> |
| In reply to | #1680865 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@kernel.org> |
|---|---|
| Date | 2017-07-04 02:30 +0200 |
| Message-ID | <tZjT3-zm-5@gated-at.bofh.it> |
| In reply to | #1680619 |
On Mon, Jul 3, 2017 at 4:55 PM, Ben Hutchings <ben@decadent.org.uk> 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 Mon, Jun 19, 2017 at 08:44:24PM +0800, Linus Torvalds wrote: >> > > > > The distros are in a different situation and don't have that >> > > > > two-week >> > > > > window until a release, and presumably would not want to cut >> > > > > over to >> > > > > something new and fairly untested on such short notice. >> > > > > >> > > > > The timing for this all sucks, but if somebody has some final >> > > > > comments, please speak up now.. >> > > > >> > > > What do you suggest the stable maintainers do here ? I've just >> > > > backported >> > > > this patch back to 3.10 and could boot it on i386 where it >> > > > apparently >> > > > works. But we may need more tests. On the other hand we benefit >> > > > from the >> > > > automated tests on tens of platforms when we push the queues so >> > > > at least >> > > > we'll quickly know if it builds and boots. I just don't feel >> > > > confident in >> > > > my work just because it builds and boots, you know. >> > > > >> > > > I'm appending the patches I currently have if anyone wants to >> > > > have a >> > > > glance. Ben, 3.2 requires much more changes than 3.10 and I'm >> > > > pretty >> > > > sure you won't change your patches at the last minute so I gave >> > > > up. >> > > >> > > Well I'm now dealing with fall-out from the Debian stable updates, >> > > which used a backport of Michal's patch series. That unfortunately >> > > seems to break programs running Java code in the main thread (the >> > > 'java' command doesn't do this, but e.g. 'jsvc' does). >> > >> > Could you share more details please? >> >> https://bugs.debian.org/865303 >> https://bugs.debian.org/865311 >> https://bugs.debian.org/865343 > > 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? That change makes sense to me.
[toc] | [prev] | [next] | [standalone]
| From | John Haxby <john.haxby@oracle.com> |
|---|---|
| Date | 2017-07-04 14:30 +0200 |
| Subject | Re: [vs-plain] Re: [PATCH] mm: larger stack guard gap, between vmas |
| Message-ID | <tZv7Q-89B-5@gated-at.bofh.it> |
| In reply to | #1680619 |
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
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | linux.kernel
csiph-web