linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andy Lutomirski <luto@kernel.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: x86-64: Maintain 16-byte stack alignment
Date: Tue, 10 Jan 2017 22:01:21 -0800	[thread overview]
Message-ID: <CALCETrX_vWTWu=kh4Zawn2OuhPnLip8xTqBGjYU-BvpJ9=ruTg@mail.gmail.com> (raw)
In-Reply-To: <20170111043541.GA4944@gondor.apana.org.au>

On Tue, Jan 10, 2017 at 8:35 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Tue, Jan 10, 2017 at 08:17:17PM -0800, Linus Torvalds wrote:
>>
>> 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.
>
> Sure we can ban the use of attribute aligned on stacks.  But
> what about indirect uses through structures?  For example, if
> someone does
>
> struct foo {
> } __attribute__ ((__aligned__(16)));
>
> int bar(...)
> {
>         struct foo f;
>
>         return baz(&f);
> }
>
> then baz will end up with an unaligned argument.  The worst part
> is that it is not at all obvious to the person writing the function
> bar.

Linus, I'm starting to lean toward agreeing with Herbert here, except
that we should consider making it conditional on having a silly GCC
version.  After all, the silly GCC versions are wasting space and time
with alignment instructions no matter what we do, so this would just
mean tweaking the asm and adding some kind of check_stack_alignment()
helper to throw out a WARN_ONCE() if we miss one.  The problem with
making it conditional is that making pt_regs effectively live at a
variable offset from %rsp is just nasty.

--Andy

  reply	other threads:[~2017-01-11  6:01 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-10 14:33 x86-64: Maintain 16-byte stack alignment Herbert Xu
2017-01-10 14:39 ` Herbert Xu
2017-01-10 17:05   ` Linus Torvalds
2017-01-10 17:09     ` Andy Lutomirski
2017-01-11  3:11     ` Herbert Xu
2017-01-11  3:30       ` Linus Torvalds
2017-01-11  4:17         ` Linus Torvalds
2017-01-11  4:35           ` Herbert Xu
2017-01-11  6:01             ` Andy Lutomirski [this message]
2017-01-12  6:21               ` Andy Lutomirski
2017-01-12  7:40                 ` Ingo Molnar
2017-01-12 14:02                 ` Josh Poimboeuf
2017-01-12 19:51                   ` Linus Torvalds
2017-01-12 20:08                     ` Andy Lutomirski
2017-01-12 20:15                       ` Josh Poimboeuf
2017-01-12 20:55                         ` Josh Poimboeuf
2017-01-12 21:40                           ` Linus Torvalds
2017-01-13  8:38                             ` Herbert Xu
2017-01-13  1:46                         ` Andy Lutomirski
2017-01-13  3:11                           ` Josh Poimboeuf
2017-01-13  3:23                             ` Andy Lutomirski
2017-01-13  4:27                               ` Josh Poimboeuf
     [not found]                                 ` <CA+55aFzRrSwGxxfZk-RUEnsz=xhcSmOwE1CenfCPBWtsS9MwDw@mail.gmail.com>
2017-01-13  5:07                                   ` Josh Poimboeuf
2017-01-13  8:43                                     ` Herbert Xu
2017-01-13  8:42                                   ` Herbert Xu
2017-01-13  8:39                           ` Herbert Xu
2017-01-13  8:36                       ` Herbert Xu
2017-01-13 13:07                         ` Josh Poimboeuf
     [not found]             ` <CA+55aFw+Z_ieo6DzTVB6_-TvQ0jj60s=T0mvXfqkBVFdKFPw_Q@mail.gmail.com>
2017-01-11  8:06               ` Ard Biesheuvel
2017-01-11  8:09                 ` Herbert Xu
2017-01-11 18:20                   ` Andy Lutomirski
2017-01-12  7:05     ` Herbert Xu
2017-01-12  7:46       ` Ingo Molnar
2017-01-12 14:49         ` Josh Poimboeuf
2017-01-12  7:51       ` Andy Lutomirski
2017-01-12  8:04         ` Herbert Xu
2017-01-12  8:18           ` Ingo Molnar
2017-01-12 15:03         ` Josh Poimboeuf
2017-01-12 15:06           ` Herbert Xu
2017-01-12 15:18             ` Josh Poimboeuf
2017-01-12 15:10           ` Josh Poimboeuf
2017-01-10 17:30 ` Ard Biesheuvel
2017-01-10 19:00   ` Andy Lutomirski
2017-01-10 19:16     ` Ard Biesheuvel
2017-01-10 19:22       ` Andy Lutomirski
2017-01-10 20:00         ` Ard Biesheuvel
2017-01-10 23:25           ` Andy Lutomirski
2017-01-11  3:26             ` Herbert Xu
2017-01-11  3:26         ` Herbert Xu
2017-01-11  3:16     ` Herbert Xu
2017-01-11  3:15   ` Herbert Xu
2017-01-12  6:12   ` Herbert Xu
2017-01-12  8:01     ` Ard Biesheuvel
2017-01-12  8:06       ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALCETrX_vWTWu=kh4Zawn2OuhPnLip8xTqBGjYU-BvpJ9=ruTg@mail.gmail.com' \
    --to=luto@amacapital.net \
    --cc=ard.biesheuvel@linaro.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).