[PATCH] D84419: Fix interaction between stack alignment and inline-asm stack clash protection

[Josh Stone via Phabricator via llvm-commits]

cuviper added inline comments.


================
Comment at: llvm/test/CodeGen/X86/stack-clash-small-large-align.ll:42
+; CHECK-NEXT:	andq	$-65536, %rsp
+; CHECK-NEXT:	addq	$65536, %rsp
+; CHECK-NEXT:	movq	%rsp, %r11
----------------
cuviper wrote:
> There's an immediate race after `andq  $-65536, %rsp` -- if we get a signal here, the stack pointer could be in a potentially bad place and start clobbering stuff.
> 
> Then adding the full alignment puts us into arbitrary stack memory, or even could go past the top of the stack. If we start writing probes from there, who knows what memory we're clobbering. (akin to @lkail's concern)
> 
> Consider if the stack is almost aligned to begin with, something like `0x1230010`. The `and` will only adjust a small distance to `0x1230000`, and then the `add` makes it `0x1240000`. The first probe will be a page below that, `0x123E000`, but that's still way out of our frame, not memory we should be writing.
> 
> Actually, that plays just as badly if the stack is perfectly aligned to begin with.
> 
> The other extreme was the original concern, perhaps with an incoming stack like `0x123FFE0`. Then it will again `and` to `0x1230000`, `add` to `0x1240000`, and start probing at `0x123E000`, which is OK in this case.
Oops, those start probing at `0x123F000`, sorry for the bad math. The point stands though.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D84419/new/

https://reviews.llvm.org/D84419