From: ard.biesheuvel@linaro.org (Ard Biesheuvel) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH 00/10] arm64: allow virtually mapped stacks to be enabled Date: Thu, 13 Jul 2017 07:51:22 +0100 [thread overview] Message-ID: <CAKv+Gu_=LVVCe29aaubPrN7Y9sP8N+DLi5dEdpJ38T7Ns61N5g@mail.gmail.com> (raw) In-Reply-To: <20170712224726.GA10559@leverpostej> On 12 July 2017 at 23:47, Mark Rutland <mark.rutland@arm.com> wrote: > Hi Ard, > > On Wed, Jul 12, 2017 at 03:44:13PM +0100, Ard Biesheuvel wrote: >> This is a fairly quick'n'dirty attempt at enabling virtually mapped >> stacks for arm64, after learning from Mark yesterday that progress >> had more or less stalled on that front. > > Thanks for putting this together. If nothing else, this work needed a > good kick. > > I had some rought comments on this, but in the process of wiring those > up, I ended up writing an alternative [1] by cobblnig together prior > attempts. Apologies for the NIH. > No worries. I deliberately refrained from any polishing of the code because I was expecting debate not acks. >> Since having actual patches to poke at is infinitely better than having >> abstract discussions about how to approach it, I threw some code together >> that: >> 1. frees up sp_el0 by promoting register x18 to 'current' pointer while in >> the kernel; flames welcome :-) (#7) >> 2. preparatory work to allow 1., i.e., to free up x18 and preserve/restore it >> correctly as a platform register (#2, #3, #4, #5, #6) > > From past experience [2], I know that Will is not a fan of reserving a > GPR like this. There are a couple of other ways we can free up SP_EL0, > though, so that isn't the end of the world. > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-July/518434.html > [2] https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/this-cpu-reg > >> 3. dump the entire task stack if regs->sp points elsewhere (#8) > > This sounds useful, but it's liable to fill a scrollbuffer and/or take a > while to dump (especially with 64K stacks), so we might want a boot-time > option to turn that on/off. > > Thanks, > Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ard.biesheuvel@linaro.org> To: Mark Rutland <mark.rutland@arm.com> Cc: "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Kernel Hardening <kernel-hardening@lists.openwall.com>, Laura Abbott <labbott@fedoraproject.org>, Will Deacon <will.deacon@arm.com>, Dave Martin <dave.martin@arm.com>, Catalin Marinas <catalin.marinas@arm.com> Subject: [kernel-hardening] Re: [RFC PATCH 00/10] arm64: allow virtually mapped stacks to be enabled Date: Thu, 13 Jul 2017 07:51:22 +0100 [thread overview] Message-ID: <CAKv+Gu_=LVVCe29aaubPrN7Y9sP8N+DLi5dEdpJ38T7Ns61N5g@mail.gmail.com> (raw) In-Reply-To: <20170712224726.GA10559@leverpostej> On 12 July 2017 at 23:47, Mark Rutland <mark.rutland@arm.com> wrote: > Hi Ard, > > On Wed, Jul 12, 2017 at 03:44:13PM +0100, Ard Biesheuvel wrote: >> This is a fairly quick'n'dirty attempt at enabling virtually mapped >> stacks for arm64, after learning from Mark yesterday that progress >> had more or less stalled on that front. > > Thanks for putting this together. If nothing else, this work needed a > good kick. > > I had some rought comments on this, but in the process of wiring those > up, I ended up writing an alternative [1] by cobblnig together prior > attempts. Apologies for the NIH. > No worries. I deliberately refrained from any polishing of the code because I was expecting debate not acks. >> Since having actual patches to poke at is infinitely better than having >> abstract discussions about how to approach it, I threw some code together >> that: >> 1. frees up sp_el0 by promoting register x18 to 'current' pointer while in >> the kernel; flames welcome :-) (#7) >> 2. preparatory work to allow 1., i.e., to free up x18 and preserve/restore it >> correctly as a platform register (#2, #3, #4, #5, #6) > > From past experience [2], I know that Will is not a fan of reserving a > GPR like this. There are a couple of other ways we can free up SP_EL0, > though, so that isn't the end of the world. > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-July/518434.html > [2] https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/this-cpu-reg > >> 3. dump the entire task stack if regs->sp points elsewhere (#8) > > This sounds useful, but it's liable to fill a scrollbuffer and/or take a > while to dump (especially with 64K stacks), so we might want a boot-time > option to turn that on/off. > > Thanks, > Mark.
next prev parent reply other threads:[~2017-07-13 6:51 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-07-12 14:44 [RFC PATCH 00/10] arm64: allow virtually mapped stacks to be enabled Ard Biesheuvel 2017-07-12 14:44 ` [kernel-hardening] " Ard Biesheuvel 2017-07-12 14:44 ` [RFC PATCH 01/10] arm64/lib: copy_page: use consistent prefetch stride Ard Biesheuvel 2017-07-12 14:44 ` [kernel-hardening] " Ard Biesheuvel 2017-07-12 14:44 ` [RFC PATCH 02/10] arm64/lib: copy_page: avoid x18 register in assembler code Ard Biesheuvel 2017-07-12 14:44 ` [kernel-hardening] " Ard Biesheuvel 2017-07-12 14:44 ` [RFC PATCH 03/10] arm64: crypto: avoid register x18 in scalar AES code Ard Biesheuvel 2017-07-12 14:44 ` [kernel-hardening] " Ard Biesheuvel 2017-07-12 14:44 ` [RFC PATCH 04/10] arm64: kvm: stop treating register x18 as caller save Ard Biesheuvel 2017-07-12 14:44 ` [kernel-hardening] " Ard Biesheuvel 2017-07-12 14:44 ` [RFC PATCH 05/10] arm64: kernel: avoid x18 as an arbitrary temp register Ard Biesheuvel 2017-07-12 14:44 ` [kernel-hardening] " Ard Biesheuvel 2017-07-12 14:44 ` [RFC PATCH 06/10] arm64: kbuild: reserve reg x18 from general allocation by the compiler Ard Biesheuvel 2017-07-12 14:44 ` [kernel-hardening] " Ard Biesheuvel 2017-07-12 14:44 ` [RFC PATCH 07/10] arm64: kernel: switch to register x18 as a task struct pointer Ard Biesheuvel 2017-07-12 14:44 ` [kernel-hardening] " Ard Biesheuvel 2017-07-13 10:41 ` Dave Martin 2017-07-13 10:41 ` [kernel-hardening] " Dave Martin 2017-07-13 12:27 ` Ard Biesheuvel 2017-07-13 12:27 ` [kernel-hardening] " Ard Biesheuvel 2017-07-13 14:11 ` Dave Martin 2017-07-13 14:11 ` [kernel-hardening] " Dave Martin 2017-07-12 14:44 ` [RFC PATCH 08/10] arm64/kernel: dump entire stack if sp points elsewhere Ard Biesheuvel 2017-07-12 14:44 ` [kernel-hardening] " Ard Biesheuvel 2017-07-12 14:44 ` [RFC PATCH 09/10] arm64: mm: add C level handling for stack overflows Ard Biesheuvel 2017-07-12 14:44 ` [kernel-hardening] " Ard Biesheuvel 2017-07-12 14:44 ` [RFC PATCH 10/10] arm64: kernel: add support for virtually mapped stacks Ard Biesheuvel 2017-07-12 14:44 ` [kernel-hardening] " Ard Biesheuvel 2017-07-12 22:59 ` Mark Rutland 2017-07-12 22:59 ` [kernel-hardening] " Mark Rutland 2017-07-13 9:12 ` Mark Rutland 2017-07-13 9:12 ` Mark Rutland 2017-07-13 10:35 ` Dave Martin 2017-07-13 10:35 ` [kernel-hardening] " Dave Martin 2017-07-12 20:12 ` [RFC PATCH 00/10] arm64: allow virtually mapped stacks to be enabled Laura Abbott 2017-07-12 20:12 ` [kernel-hardening] " Laura Abbott 2017-07-12 20:49 ` Ard Biesheuvel 2017-07-12 20:49 ` [kernel-hardening] " Ard Biesheuvel 2017-07-12 21:32 ` Andy Lutomirski 2017-07-12 21:32 ` [kernel-hardening] " Andy Lutomirski 2017-07-12 22:47 ` Mark Rutland 2017-07-12 22:47 ` [kernel-hardening] " Mark Rutland 2017-07-13 6:51 ` Ard Biesheuvel [this message] 2017-07-13 6:51 ` 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_=LVVCe29aaubPrN7Y9sP8N+DLi5dEdpJ38T7Ns61N5g@mail.gmail.com' \ --to=ard.biesheuvel@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ /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.