From: Ard Biesheuvel <ard.biesheuvel@linaro.org> To: Mark Rutland <mark.rutland@arm.com> Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Takahiro Akashi <akashi.takahiro@linaro.org>, Catalin Marinas <catalin.marinas@arm.com>, Dave Martin <dave.martin@arm.com>, James Morse <james.morse@arm.com>, Laura Abbott <labbott@fedoraproject.org>, Will Deacon <will.deacon@arm.com>, Kees Cook <keescook@chromium.org> Subject: Re: [kernel-hardening] Re: [RFC PATCH 6/6] arm64: add VMAP_STACK and detect out-of-bounds SP Date: Fri, 14 Jul 2017 13:55:31 +0100 [thread overview] Message-ID: <CAKv+Gu-STA0zV5-s7b3WKkKAJePWKAAP8r3zPSO_JFWC3ZBiTA@mail.gmail.com> (raw) In-Reply-To: <20170714125214.GA16687@leverpostej> On 14 July 2017 at 13:52, Mark Rutland <mark.rutland@arm.com> wrote: > On Fri, Jul 14, 2017 at 11:48:20AM +0100, Ard Biesheuvel wrote: >> On 14 July 2017 at 11:32, Mark Rutland <mark.rutland@arm.com> wrote: >> > On Thu, Jul 13, 2017 at 07:28:48PM +0100, Ard Biesheuvel wrote: >> >> On 13 July 2017 at 18:55, Mark Rutland <mark.rutland@arm.com> wrote: >> >> > On Thu, Jul 13, 2017 at 05:10:50PM +0100, Mark Rutland wrote: >> >> >> On Thu, Jul 13, 2017 at 12:49:48PM +0100, Ard Biesheuvel wrote: >> >> >> > On 13 July 2017 at 11:49, Mark Rutland <mark.rutland@arm.com> wrote: >> >> >> > > On Thu, Jul 13, 2017 at 07:58:50AM +0100, Ard Biesheuvel wrote: >> >> >> > >> On 12 July 2017 at 23:33, Mark Rutland <mark.rutland@arm.com> wrote: >> > This means that we have to align the initial task, so the kernel Image >> > will grow by THREAD_SIZE. Likewise for IRQ stacks, unless we can rework >> > things such that we can dynamically allocate all of those. >> > >> >> We can't currently do that for 64k pages, since the segment alignment >> is only 64k. But we should be able to patch that up I think > > I was assuming that the linked would bump up the segment alignment if a > more-aligned object were placed inside. I guess that doesn't happen in > all cases? > > ... or do you mean when the EFI stub relocates the kernel, assuming > relaxed alignment constraints? > No, I mean under KASLR, which randomizes at SEGMENT_ALIGN granularity. >> >> >> I believe that determining whether the exception was caused by a stack >> >> >> overflow is not something we can do robustly or efficiently. >> >> >> >> Actually, if the stack pointer is within S_FRAME_SIZE of the base, and >> >> the faulting address points into the guard page, that is a pretty >> >> strong indicator that the stack overflowed. That shouldn't be too >> >> costly? >> > >> > Sure, but that's still a a heuristic. For example, that also catches an >> > unrelated vmalloc address gone wrong, while SP was close to the end of >> > the stack. >> >> Yes, but the likelihood that an unrelated stray vmalloc access is >> within 16 KB of a stack pointer that is close ot its limit is >> extremely low, so we should be able to live with the risk of >> misidentifying it. > > I guess, but at that point, why bother? > > That gives us a fuzzy check for one specific "stack overflow", while not > catching the general case. > > So long as we have a reliable stack trace, we can figure out that was > the case, and we don't set the expectation that we're trying to > categorize the general case (minefield and all). > Yes. As long as the context is described accurately, there is no need to make any inferences on behalf of the user.
WARNING: multiple messages have this Message-ID (diff)
From: ard.biesheuvel@linaro.org (Ard Biesheuvel) To: linux-arm-kernel@lists.infradead.org Subject: [kernel-hardening] Re: [RFC PATCH 6/6] arm64: add VMAP_STACK and detect out-of-bounds SP Date: Fri, 14 Jul 2017 13:55:31 +0100 [thread overview] Message-ID: <CAKv+Gu-STA0zV5-s7b3WKkKAJePWKAAP8r3zPSO_JFWC3ZBiTA@mail.gmail.com> (raw) In-Reply-To: <20170714125214.GA16687@leverpostej> On 14 July 2017 at 13:52, Mark Rutland <mark.rutland@arm.com> wrote: > On Fri, Jul 14, 2017 at 11:48:20AM +0100, Ard Biesheuvel wrote: >> On 14 July 2017 at 11:32, Mark Rutland <mark.rutland@arm.com> wrote: >> > On Thu, Jul 13, 2017 at 07:28:48PM +0100, Ard Biesheuvel wrote: >> >> On 13 July 2017 at 18:55, Mark Rutland <mark.rutland@arm.com> wrote: >> >> > On Thu, Jul 13, 2017 at 05:10:50PM +0100, Mark Rutland wrote: >> >> >> On Thu, Jul 13, 2017 at 12:49:48PM +0100, Ard Biesheuvel wrote: >> >> >> > On 13 July 2017 at 11:49, Mark Rutland <mark.rutland@arm.com> wrote: >> >> >> > > On Thu, Jul 13, 2017 at 07:58:50AM +0100, Ard Biesheuvel wrote: >> >> >> > >> On 12 July 2017 at 23:33, Mark Rutland <mark.rutland@arm.com> wrote: >> > This means that we have to align the initial task, so the kernel Image >> > will grow by THREAD_SIZE. Likewise for IRQ stacks, unless we can rework >> > things such that we can dynamically allocate all of those. >> > >> >> We can't currently do that for 64k pages, since the segment alignment >> is only 64k. But we should be able to patch that up I think > > I was assuming that the linked would bump up the segment alignment if a > more-aligned object were placed inside. I guess that doesn't happen in > all cases? > > ... or do you mean when the EFI stub relocates the kernel, assuming > relaxed alignment constraints? > No, I mean under KASLR, which randomizes at SEGMENT_ALIGN granularity. >> >> >> I believe that determining whether the exception was caused by a stack >> >> >> overflow is not something we can do robustly or efficiently. >> >> >> >> Actually, if the stack pointer is within S_FRAME_SIZE of the base, and >> >> the faulting address points into the guard page, that is a pretty >> >> strong indicator that the stack overflowed. That shouldn't be too >> >> costly? >> > >> > Sure, but that's still a a heuristic. For example, that also catches an >> > unrelated vmalloc address gone wrong, while SP was close to the end of >> > the stack. >> >> Yes, but the likelihood that an unrelated stray vmalloc access is >> within 16 KB of a stack pointer that is close ot its limit is >> extremely low, so we should be able to live with the risk of >> misidentifying it. > > I guess, but at that point, why bother? > > That gives us a fuzzy check for one specific "stack overflow", while not > catching the general case. > > So long as we have a reliable stack trace, we can figure out that was > the case, and we don't set the expectation that we're trying to > categorize the general case (minefield and all). > Yes. As long as the context is described accurately, there is no need to make any inferences on behalf of the user.
next prev parent reply other threads:[~2017-07-14 12:55 UTC|newest] Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-07-12 22:32 [RFC PATCH 0/6] arm64: alternative VMAP_STACK implementation Mark Rutland 2017-07-12 22:32 ` [kernel-hardening] " Mark Rutland 2017-07-12 22:32 ` Mark Rutland 2017-07-12 22:32 ` [RFC PATCH 1/6] arm64: use tpidr_el1 for current, free sp_el0 Mark Rutland 2017-07-12 22:32 ` [kernel-hardening] " Mark Rutland 2017-07-12 22:32 ` Mark Rutland 2017-07-14 1:30 ` Will Deacon 2017-07-14 1:30 ` [kernel-hardening] " Will Deacon 2017-07-14 1:30 ` Will Deacon 2017-07-12 22:32 ` [RFC PATCH 2/6] arm64: avoid open-coding THREAD_SIZE{,_ORDER} Mark Rutland 2017-07-12 22:32 ` [kernel-hardening] " Mark Rutland 2017-07-12 22:32 ` Mark Rutland 2017-07-13 10:18 ` James Morse 2017-07-13 10:18 ` [kernel-hardening] " James Morse 2017-07-13 10:18 ` James Morse 2017-07-13 11:26 ` Mark Rutland 2017-07-13 11:26 ` [kernel-hardening] " Mark Rutland 2017-07-13 11:26 ` Mark Rutland 2017-07-12 22:33 ` [RFC PATCH 3/6] arm64: pad stacks to PAGE_SIZE for VMAP_STACK Mark Rutland 2017-07-12 22:33 ` [kernel-hardening] " Mark Rutland 2017-07-12 22:33 ` Mark Rutland 2017-07-12 22:33 ` [RFC PATCH 4/6] arm64: pass stack base to secondary_start_kernel Mark Rutland 2017-07-12 22:33 ` [kernel-hardening] " Mark Rutland 2017-07-12 22:33 ` Mark Rutland 2017-07-12 22:33 ` [RFC PATCH 5/6] arm64: keep track of current stack Mark Rutland 2017-07-12 22:33 ` [kernel-hardening] " Mark Rutland 2017-07-12 22:33 ` Mark Rutland 2017-07-12 22:33 ` [RFC PATCH 6/6] arm64: add VMAP_STACK and detect out-of-bounds SP Mark Rutland 2017-07-12 22:33 ` [kernel-hardening] " Mark Rutland 2017-07-12 22:33 ` Mark Rutland 2017-07-13 6:58 ` Ard Biesheuvel 2017-07-13 6:58 ` [kernel-hardening] " Ard Biesheuvel 2017-07-13 6:58 ` Ard Biesheuvel 2017-07-13 10:49 ` Mark Rutland 2017-07-13 10:49 ` [kernel-hardening] " Mark Rutland 2017-07-13 10:49 ` Mark Rutland 2017-07-13 11:49 ` Ard Biesheuvel 2017-07-13 11:49 ` [kernel-hardening] " Ard Biesheuvel 2017-07-13 11:49 ` Ard Biesheuvel 2017-07-13 16:10 ` Mark Rutland 2017-07-13 16:10 ` [kernel-hardening] " Mark Rutland 2017-07-13 16:10 ` Mark Rutland 2017-07-13 17:55 ` [kernel-hardening] " Mark Rutland 2017-07-13 17:55 ` Mark Rutland 2017-07-13 17:55 ` Mark Rutland 2017-07-13 18:28 ` Ard Biesheuvel 2017-07-13 18:28 ` Ard Biesheuvel 2017-07-13 18:28 ` Ard Biesheuvel 2017-07-14 10:32 ` Mark Rutland 2017-07-14 10:32 ` Mark Rutland 2017-07-14 10:32 ` Mark Rutland 2017-07-14 10:48 ` Ard Biesheuvel 2017-07-14 10:48 ` Ard Biesheuvel 2017-07-14 10:48 ` Ard Biesheuvel 2017-07-14 12:27 ` Ard Biesheuvel 2017-07-14 12:27 ` Ard Biesheuvel 2017-07-14 12:27 ` Ard Biesheuvel 2017-07-14 14:06 ` Mark Rutland 2017-07-14 14:06 ` Mark Rutland 2017-07-14 14:06 ` Mark Rutland 2017-07-14 14:14 ` Ard Biesheuvel 2017-07-14 14:14 ` Ard Biesheuvel 2017-07-14 14:14 ` Ard Biesheuvel 2017-07-14 14:39 ` Robin Murphy 2017-07-14 14:39 ` Robin Murphy 2017-07-14 14:39 ` Robin Murphy 2017-07-14 15:03 ` Robin Murphy 2017-07-14 15:03 ` Robin Murphy 2017-07-14 15:03 ` Robin Murphy 2017-07-14 15:15 ` Ard Biesheuvel 2017-07-14 15:15 ` Ard Biesheuvel 2017-07-14 15:15 ` Ard Biesheuvel 2017-07-14 15:25 ` Mark Rutland 2017-07-14 15:25 ` Mark Rutland 2017-07-14 15:25 ` Mark Rutland 2017-07-14 21:27 ` Mark Rutland 2017-07-14 21:27 ` Mark Rutland 2017-07-14 21:27 ` Mark Rutland 2017-07-16 0:03 ` Ard Biesheuvel 2017-07-16 0:03 ` Ard Biesheuvel 2017-07-16 0:03 ` Ard Biesheuvel 2017-07-18 21:53 ` Laura Abbott 2017-07-18 21:53 ` Laura Abbott 2017-07-18 21:53 ` Laura Abbott 2017-07-19 8:08 ` Ard Biesheuvel 2017-07-19 8:08 ` Ard Biesheuvel 2017-07-19 8:08 ` Ard Biesheuvel 2017-07-19 23:32 ` Laura Abbott 2017-07-19 23:32 ` Laura Abbott 2017-07-20 5:35 ` Ard Biesheuvel 2017-07-20 5:35 ` Ard Biesheuvel 2017-07-20 5:35 ` Ard Biesheuvel 2017-07-20 8:36 ` James Morse 2017-07-20 8:36 ` James Morse 2017-07-20 8:36 ` James Morse 2017-07-20 8:56 ` Ard Biesheuvel 2017-07-20 8:56 ` Ard Biesheuvel 2017-07-20 8:56 ` Ard Biesheuvel 2017-07-20 17:30 ` Ard Biesheuvel 2017-07-20 17:30 ` Ard Biesheuvel 2017-07-20 17:30 ` Ard Biesheuvel 2017-07-20 19:10 ` Laura Abbott 2017-07-20 19:10 ` Laura Abbott 2017-07-20 19:10 ` Laura Abbott 2017-07-14 12:52 ` Mark Rutland 2017-07-14 12:52 ` Mark Rutland 2017-07-14 12:52 ` Mark Rutland 2017-07-14 12:55 ` Ard Biesheuvel [this message] 2017-07-14 12:55 ` Ard Biesheuvel 2017-07-14 12:55 ` Ard Biesheuvel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAKv+Gu-STA0zV5-s7b3WKkKAJePWKAAP8r3zPSO_JFWC3ZBiTA@mail.gmail.com \ --to=ard.biesheuvel@linaro.org \ --cc=akashi.takahiro@linaro.org \ --cc=catalin.marinas@arm.com \ --cc=dave.martin@arm.com \ --cc=james.morse@arm.com \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=labbott@fedoraproject.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.