From: James Morse <james.morse@arm.com> To: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Laura Abbott <labbott@redhat.com>, Mark Rutland <mark.rutland@arm.com>, 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>, 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: Thu, 20 Jul 2017 09:36:18 +0100 [thread overview] Message-ID: <59706B82.1030601@arm.com> (raw) In-Reply-To: <CAKv+Gu_JNNVvLaSt3PTOexJV4HzPUN0mLOm6YYRS8d=UOafopQ@mail.gmail.com> Hi Ard, On 20/07/17 06:35, Ard Biesheuvel wrote: > On 20 July 2017 at 00:32, Laura Abbott <labbott@redhat.com> wrote: >> I didn't notice any performance impact but I also wasn't trying that >> hard. I did try this with a different configuration and ran into >> stackspace errors almost immediately: >> >> [ 0.358026] smp: Brought up 1 node, 8 CPUs >> [ 0.359359] SMP: Total of 8 processors activated. >> [ 0.359542] CPU features: detected feature: 32-bit EL0 Support >> [ 0.361781] Insufficient stack space to handle exception! [...] >> [ 0.367382] Task stack: [0xffffff8008e80000..0xffffff8008e84000] >> [ 0.367519] IRQ stack: [0xffffffc03bf62000..0xffffffc03bf66000] > > The IRQ stack is not 16K aligned ... >> [ 0.367687] ESR: 0x00000000 -- Unknown/Uncategorized >> [ 0.367868] FAR: 0x0000000000000000 >> [ 0.368059] Kernel panic - not syncing: kernel stack overflow >> [ 0.368252] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.12.0-00018-ge9cf49d604ef-dirty #23 >> [ 0.368427] Hardware name: linux,dummy-virt (DT) >> [ 0.368612] Call trace: >> [ 0.368774] [<ffffff8008087fd8>] dump_backtrace+0x0/0x228 >> [ 0.368979] [<ffffff80080882c8>] show_stack+0x10/0x20 >> [ 0.369270] [<ffffff80084602dc>] dump_stack+0x88/0xac >> [ 0.369459] [<ffffff800816328c>] panic+0x120/0x278 >> [ 0.369582] [<ffffff8008088b40>] handle_bad_stack+0xd0/0xd8 >> [ 0.369799] [<ffffff80080bfb94>] __do_softirq+0x74/0x210 >> [ 0.370560] SMP: stopping secondary CPUs >> [ 0.384269] Rebooting in 5 seconds.. >> >> The config is based on what I use for booting my Hikey android >> board. I haven't been able to narrow down exactly which >> set of configs set this off. >> > > ... so for some reason, the percpu atom size change fails to take effect here. I'm not completely up to speed with these series, so this may be noise: When we added the IRQ stack Jungseok Lee discovered that alignment greater than PAGE_SIZE only applies to CPU0. Secondary CPUs read the per-cpu init data into a page-aligned area, but any greater alignment requirement is lost. Because of this the irqstack was only 16byte aligned, and struct thread_info had to be be discovered without depending on stack alignment. Thanks, James
WARNING: multiple messages have this Message-ID (diff)
From: james.morse@arm.com (James Morse) 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: Thu, 20 Jul 2017 09:36:18 +0100 [thread overview] Message-ID: <59706B82.1030601@arm.com> (raw) In-Reply-To: <CAKv+Gu_JNNVvLaSt3PTOexJV4HzPUN0mLOm6YYRS8d=UOafopQ@mail.gmail.com> Hi Ard, On 20/07/17 06:35, Ard Biesheuvel wrote: > On 20 July 2017 at 00:32, Laura Abbott <labbott@redhat.com> wrote: >> I didn't notice any performance impact but I also wasn't trying that >> hard. I did try this with a different configuration and ran into >> stackspace errors almost immediately: >> >> [ 0.358026] smp: Brought up 1 node, 8 CPUs >> [ 0.359359] SMP: Total of 8 processors activated. >> [ 0.359542] CPU features: detected feature: 32-bit EL0 Support >> [ 0.361781] Insufficient stack space to handle exception! [...] >> [ 0.367382] Task stack: [0xffffff8008e80000..0xffffff8008e84000] >> [ 0.367519] IRQ stack: [0xffffffc03bf62000..0xffffffc03bf66000] > > The IRQ stack is not 16K aligned ... >> [ 0.367687] ESR: 0x00000000 -- Unknown/Uncategorized >> [ 0.367868] FAR: 0x0000000000000000 >> [ 0.368059] Kernel panic - not syncing: kernel stack overflow >> [ 0.368252] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.12.0-00018-ge9cf49d604ef-dirty #23 >> [ 0.368427] Hardware name: linux,dummy-virt (DT) >> [ 0.368612] Call trace: >> [ 0.368774] [<ffffff8008087fd8>] dump_backtrace+0x0/0x228 >> [ 0.368979] [<ffffff80080882c8>] show_stack+0x10/0x20 >> [ 0.369270] [<ffffff80084602dc>] dump_stack+0x88/0xac >> [ 0.369459] [<ffffff800816328c>] panic+0x120/0x278 >> [ 0.369582] [<ffffff8008088b40>] handle_bad_stack+0xd0/0xd8 >> [ 0.369799] [<ffffff80080bfb94>] __do_softirq+0x74/0x210 >> [ 0.370560] SMP: stopping secondary CPUs >> [ 0.384269] Rebooting in 5 seconds.. >> >> The config is based on what I use for booting my Hikey android >> board. I haven't been able to narrow down exactly which >> set of configs set this off. >> > > ... so for some reason, the percpu atom size change fails to take effect here. I'm not completely up to speed with these series, so this may be noise: When we added the IRQ stack Jungseok Lee discovered that alignment greater than PAGE_SIZE only applies to CPU0. Secondary CPUs read the per-cpu init data into a page-aligned area, but any greater alignment requirement is lost. Because of this the irqstack was only 16byte aligned, and struct thread_info had to be be discovered without depending on stack alignment. Thanks, James
next prev parent reply other threads:[~2017-07-20 8:38 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 [this message] 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 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=59706B82.1030601@arm.com \ --to=james.morse@arm.com \ --cc=akashi.takahiro@linaro.org \ --cc=ard.biesheuvel@linaro.org \ --cc=catalin.marinas@arm.com \ --cc=dave.martin@arm.com \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=labbott@fedoraproject.org \ --cc=labbott@redhat.com \ --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.