[PATCH 0/7] Ensure stack is aligned for kernel entries

[Ramana.Radhakrishnan@arm.com (Ramana Radhakrishnan)]

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 <julien.thierry@arm.com> wrote:
>>>>
>>>>
>>>> On 08/11/18 13:04, Ard Biesheuvel wrote:
>>>>>
>>>>> On 26 September 2018 at 15:56, Julien Thierry <julien.thierry@arm.com>
>>>>> 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
>>
>> <quote>
>>
>> 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
>>
>> </end quote>
>>
> 
> 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.

regards
Ramana
> 
> Thanks,
>