From mboxrd@z Thu Jan 1 00:00:00 1970 From: julien.thierry@arm.com (Julien Thierry) Date: Thu, 8 Nov 2018 15:41:35 +0000 Subject: [PATCH 0/7] Ensure stack is aligned for kernel entries In-Reply-To: <9073dd77-84f3-3a90-0d22-b3700da319f7@arm.com> References: <1537970184-44348-1-git-send-email-julien.thierry@arm.com> <8382cafd-9fb7-7121-0de2-5091ba079d31@arm.com> <45592bdd-2f2f-211b-8d58-bcc2c651509e@arm.com> <9073dd77-84f3-3a90-0d22-b3700da319f7@arm.com> Message-ID: <4ec172fe-0368-491d-f166-9316d01f8b12@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 08/11/18 15:33, Ramana Radhakrishnan wrote: > On 08/11/2018 15:01, Julien Thierry wrote: >> >> >> On 08/11/18 14:19, Ramana Radhakrishnan wrote: >>> On 08/11/2018 14:10, Ard Biesheuvel wrote: >>>> (+ Ramana) >>>> >>>> On 8 November 2018 at 14:27, Julien Thierry wrote: >>>>> >>>>> >>>>> On 08/11/18 13:04, Ard Biesheuvel wrote: >>>>>> >>>>>> On 26 September 2018 at 15:56, Julien Thierry >>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Having SCTLR_ELx.SA enabled requires the SP to be 16-bytes aligned before >>>>>>> using it to access memory. When taking an exception, it is possible that >>>>>>> the context during which the exception occured had SP mis-aligned. >>>>>> >>>>>> >>>>>> How is this possible? GCC clearly only manipulates the stack pointer >>>>>> in 16 byte multiples, and so if we do the same in our asm code (which >>>>>> I think we already do, given the lack of reports about this issue), is >>>>>> this handling really necessary? >>>>>> >>>>> >>>>> Is there anything that actually gives us that guarantee from GCC? I agree >>>>> that currently it looks like aarch64-<...>-gcc only manipulates SP aligned >>>>> to 16 bytes, but I don't know whether that is certain. >>>>> >>>> >>>> I think we should get that clarified then. I don't think it makes >>>> sense for GCC to have to reason about whether SP currently has a value >>>> that permits dereferencing. >>> >>> The ABI gives that guarantee. >>> >>> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf >>> >>> >>> >>> 5.2.2.1 Universal stack constraints >>> >>> <...> >>> >>> Additionally, at any point at which memory is accessed >>> via SP, the hardware requires that SP mod 16 = 0. The stack must be >>> quad-word aligned >>> >>> >>> >> >> Thanks Ramana. Sadly I don't think this clarifies things. The issue is >> that the guarantee is only that SP is aligned when we will use it to >> access memory, but still allows for a scenario like: > > > That is certainly a correct interpretation of the ABI language. > >> >> -> Updating SP with non 16bytes-aligned value (it's fine as long as the >> following code takes care to align it before accessing memory) >> -> IRQ is raised before SP gets aligned >> -> Vector entry starts saving context on misaligned stack >> -> Misaligned SP exception >> >> The only thing that would avoid us the trouble is a guarantee that GCC >> never modifies SP in such a way that SP is not 16-bytes aligned. > > > I think it sort of falls out in the implementation from what I remember > and see (and empirically checked with a couple of colleagues). > > I don't think there is an ABI requirement that SP should left 16 byte > aligned even for intermediate calculations. > > Whether GCC does this or not today is immaterial and for userland it's > certainly not the only code generator in town for this sort of question. > The question also arises with other jits and other code generators which > may leave the stack temporarily not aligned at 16 bytes. So it does > sound like the right thing to do in the kernel defensively. > I don't think we really mind about userland. EL1 can (and, in Linux, does) use it's own SP. So having an interrupt while EL0 has a misaligned SP is not an issue for the kernel. The cases covered by this series in only for exceptions received at the same EL that will handle that exception. Cheers, -- Julien Thierry