* Herbert Xu <herb...@gondor.apana.org.au> wrote:
> > But if we can't do this with automatic verification, then I'm not sure
> > I want to do it at all. The asm is already more precarious than I'd
> > like, and having a code path that is misaligned is asking for obscure
> > bugs down the road.
>
> I understand the need for automated checks at this point in time.
> But longer term this is just part of the calling ABI. After all,
> we don't add checks everywhere to ensure people preserve rbx.
The intelligent and responsible way to introduce such post facto ABI changes is
via a smarter assembler: which would detect the obvious cases where assembly
code
generates a misaligned stack, at build time.
Assembly code can obviously still mess up in a hard to detect fashion if it
tries
- but that's OK, as most assembly code doesn't try to go outside regular stack
allocation patterns.
Such a static check is relatively straightforward to do in assembly tooling -
and
perhaps objtool could do this too, as it already tracks the instructions that
change the stack offset.
( And yes, this is what the GCC guys should have done, instead of sloppily
introducing such silent breakages and making the whole application landscape
less robust ... )
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
