* Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
