All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthias Kaehlcke <mka@chromium.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Chris J Arges <chris.j.arges@canonical.com>,
	Borislav Petkov <bp@suse.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Douglas Anderson <dianders@chromium.org>,
	Michael Davidson <md@google.com>,
	Greg Hackmann <ghackmann@google.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Stephen Hines <srhines@google.com>,
	Kees Cook <keescook@chromium.org>, Arnd Bergmann <arnd@arndb.de>,
	Bernhard.Rosenkranzer@linaro.org
Subject: Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"
Date: Wed, 12 Jul 2017 15:20:40 -0700	[thread overview]
Message-ID: <20170712222040.GD95735@google.com> (raw)
In-Reply-To: <20170712221242.puv5illztsla4nph@treble>

Hi Josh,

thanks for your prompt reply.

El Wed, Jul 12, 2017 at 05:12:42PM -0500 Josh Poimboeuf ha dit:

> On Wed, Jul 12, 2017 at 02:27:44PM -0700, Matthias Kaehlcke wrote:
> > Commit f05058c4d652 supposedly "forces a stack frame to be created before
> > the inline asm code if CONFIG_FRAME_POINTER is enabled by listing the
> > stack pointer as an output operand for the get_user() inline assembly
> > statement.". This doesn't work as intended, at least with gcc v4.9.2 and
> > x86-64 the generated code is exactly the same with and without the patch.
> > However clang adds an extra instruction that adjusts %rsp, which ends up
> > causing double faults all over the place.
> 
> I don't think reverting it is the right approach, because that will
> still break frame pointers in certain cases.
> 
> The original commit probably should have clarified:
> 
>  " ... forces a stack frame *if it doesn't already exist*."
>
>
> In *most* cases it will have no effect, as you saw, because users of
> get_user() tend to do other function calls beforehand, so they will have
> already saved the frame pointer before calling it.
> 
> However, that isn't always the case.  We found that certain configs
> change GCC's behavior such that, for certain get_user() call sites, the
> containing function doesn't saved the frame pointer before inserting
> get_user()'s inline asm.
> 
> GCC completely ignores inline asm, so it has no idea that it has a call
> instruction in it.  So in general, *any* inline asm with a call
> instruction needs this constraint, to force the frame pointer to be
> saved, if it hasn't already.

Thanks for the clarification!

> This is admittedly an awkward way of achieving this goal, but it's the
> only way I know how to do it with GCC.
> 
> What extra instruction does clang add?

I was looking at the get_user() call in drm_mode_setcrtc(). The code
generated by clang without the patch is:

                        if (get_user(out_id, &set_connectors_ptr[i])) {
ffffffff81386955:       4a 8d 04 bd 00 00 00    lea    0x0(,%r15,4),%rax
ffffffff8138695c:       00 
ffffffff8138695d:       49 03 06                add    (%r14),%rax
ffffffff81386960:       e8 2b a5 f0 ff          callq  ffffffff81290e90 <__get_user_4>

And with the patch:

                        if (get_user(out_id, &set_connectors_ptr[i])) {
ffffffff81386a56:       4a 8d 04 bd 00 00 00    lea    0x0(,%r15,4),%rax
ffffffff81386a5d:       00 
ffffffff81386a5e:       49 03 06                add    (%r14),%rax
ffffffff81386a61:       48 8b 64 24 28          mov    0x28(%rsp),%rsp
ffffffff81386a66:       e8 15 a5 f0 ff          callq
ffffffff81290f80 <__get_user_4>

  reply	other threads:[~2017-07-12 22:20 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-12 21:27 [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm" Matthias Kaehlcke
2017-07-12 22:12 ` Josh Poimboeuf
2017-07-12 22:20   ` Matthias Kaehlcke [this message]
2017-07-12 22:35     ` Josh Poimboeuf
2017-07-12 22:36       ` Josh Poimboeuf
2017-07-12 23:22         ` Matthias Kaehlcke
2017-07-13 18:00           ` Josh Poimboeuf
2017-07-13 18:47             ` Matthias Kaehlcke
2017-07-13 19:25               ` Josh Poimboeuf
2017-07-13 19:38                 ` Michael Davidson
2017-07-13 20:18                   ` Josh Poimboeuf
2017-07-13 20:20               ` Andrey Rybainin
2017-07-13 20:34                 ` Josh Poimboeuf
2017-07-13 21:12                   ` Matthias Kaehlcke
2017-07-13 21:34                     ` Josh Poimboeuf
2017-07-13 21:57                       ` Matthias Kaehlcke
2017-07-19 17:46                         ` Josh Poimboeuf
2017-07-19 21:50                           ` Matthias Kaehlcke
2017-07-20 10:01                           ` Andrey Ryabinin
2017-07-20 15:18                             ` Josh Poimboeuf
2017-07-20 15:30                               ` Andrey Ryabinin
2017-07-20 20:56                                 ` Josh Poimboeuf
2017-07-21  9:13                                   ` Andrey Ryabinin
2017-07-21 13:24                                     ` Josh Poimboeuf
2017-07-29  0:38                                   ` Matthias Kaehlcke
2017-07-29  0:55                                     ` Josh Poimboeuf
2017-07-29  0:58                                       ` Josh Poimboeuf
2017-07-29  1:06                                       ` Matthias Kaehlcke
2017-07-13 21:14                 ` Matthias Kaehlcke
2017-07-13 21:25                   ` Andrey Rybainin
2017-07-13 21:43                     ` Matthias Kaehlcke
2017-07-13 21:52                       ` Josh Poimboeuf

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=20170712222040.GD95735@google.com \
    --to=mka@chromium.org \
    --cc=Bernhard.Rosenkranzer@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bp@suse.de \
    --cc=chris.j.arges@canonical.com \
    --cc=dianders@chromium.org \
    --cc=ghackmann@google.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=md@google.com \
    --cc=mingo@redhat.com \
    --cc=ndesaulniers@google.com \
    --cc=srhines@google.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.