From: Linus Torvalds Subject: Re: x86-64: Maintain 16-byte stack alignment Date: Tue, 10 Jan 2017 20:17:17 -0800 Message-ID: References: <20170110143340.GA3787@gondor.apana.org.au> <20170110143913.GA3822@gondor.apana.org.au> <20170111031124.GA4515@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Linux Kernel Mailing List , Linux Crypto Mailing List , Ingo Molnar , Thomas Gleixner , Andy Lutomirski , Ard Biesheuvel To: Herbert Xu Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org On Tue, Jan 10, 2017 at 7:30 PM, Linus Torvalds wrote: > > If you really want more stack alignment, you have to generate that > alignment yourself by hand (and have a bigger buffer that you do that > alignment inside). Side note: gcc can (and does) actually generate forced alignment using "and" instructions on %rsp rather than assuming pre-existing alignment. And that would be valid. The problem with "alignof(16)" is not that gcc couldn't generate the alignment itself, it's just the broken "it's already aligned to 16 bytes" assumption because -mpreferred-stack-boundary=3 doesn't work. You *could* try to hack around it by forcing a 32-byte alignment instead. That (I think) will make gcc generate the "and" instruction mess. And it shouldn't actually use any more memory than doing it by hand (by having twice the alignment and hand-aligning the pointer). So we *could* try to just have a really hacky rule saying that you can align stack data to 8 or 32 bytes, but *not* to 16 bytes. That said, I do think that the "don't assume stack alignment, do it by hand" may be the safer thing. Because who knows what the random rules will be on other architectures. Linus