Ensure stack is aligned for kernel entries
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 7 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 7 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/7] Ensure stack is aligned for kernel entries
Quoted 15 lines · Ard Biesheuvel
Quoted 5 lines · Julien Thierry
On 26/09/18 14:56, Julien Thierry wrote:
There is just one case remaining, which is less important as it is mostly a debug concern. If we take an SP alignment fault from EL1 (due to bad implementation) we take recursive exceptions:Quoted 8 lines
- Without
CONFIG_VMAP_STACK, kernel just freezes always taking SP alignment faults
- WithCONFIG_VMAP_STACKafter taking a number of exceptions, we overflow the stack and the kernel switches to the overflow stack where it finally manages to display a kernel panic messageSo the question is, do we care about doing something for the above case?
Quoted 8 lines
So in the latter case, it is obvious from the debug output that the stack pointer was misaligned? I'd expect so, given that each recursively taken exception has the same cause, and so it would be clear what happened.
So I'm leaning towards just relying on that, given that
CONFIG_VMAP_STACKis the default, although it is unfortunate that KASAN still disables it.
Whilst it's unfortunate, I don't think it's the end of the world as long as KASAN remains a debug-only feature. In that case, you'd only enable it if you were debugging a suspected use-after-free, and I think the splat you'd see from the overflow is clear enough that it's not one of those.
However, I really would like a written confirmation (i.e. in some documentation) from GCC that they won't misalign the SP in generated code before we drop the meat of this series.
Will