From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ramana.Radhakrishnan@arm.com (Ramana Radhakrishnan) Date: Thu, 8 Nov 2018 14:19:14 +0000 Subject: [PATCH 0/7] Ensure stack is aligned for kernel entries In-Reply-To: References: <1537970184-44348-1-git-send-email-julien.thierry@arm.com> <8382cafd-9fb7-7121-0de2-5091ba079d31@arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 regards Ramana