linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthias Kaehlcke <mka@chromium.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: "Andrey Ryabinin" <ryabinin.a.a@gmail.com>,
	"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" <x86@kernel.org>,
	LKML <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 Rosenkränzer" <Bernhard.Rosenkranzer@linaro.org>
Subject: Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"
Date: Fri, 28 Jul 2017 17:38:52 -0700	[thread overview]
Message-ID: <20170729003852.GD84665@google.com> (raw)
In-Reply-To: <20170720205652.patvjnfqymrv73ho@treble>

El Thu, Jul 20, 2017 at 03:56:52PM -0500 Josh Poimboeuf ha dit:

> On Thu, Jul 20, 2017 at 06:30:24PM +0300, Andrey Ryabinin wrote:
> > FWIW bellow is my understanding of what's going on.
> > 
> > It seems clang treats local named register almost the same as ordinary
> > local variables.
> > The only difference is that before reading the register variable clang
> > puts variable's value into the specified register.
> > 
> > So clang just assigns stack slot for the variable __sp where it's
> > going to keep variable's value.
> > But since __sp is unitialized (we haven't assign anything to it), the
> > value of the __sp is some garbage from stack.
> > inline asm specifies __sp as input, so clang assumes that it have to
> > load __sp into 'rsp' because inline asm is going to use
> > it. And it just loads garbage from stack into 'rsp'
> > 
> > In fact, such behavior (I mean storing the value on stack and loading
> > into reg before the use) is very useful.
> > Clang's behavior allows to keep the value assigned to the
> > call-clobbered register across the function calls.
> > 
> > Unlike clang, gcc assigns value to the register right away and doesn't
> > store the value anywhere else. So if the reg is
> > call clobbered register you have to be absolutely sure that there is
> > no subsequent function call that might clobber the register.
> > 
> > E.g. see some real examples
> > https://patchwork.kernel.org/patch/4111971/ or 98d4ded60bda("msm: scm:
> > Fix improper register assignment").
> > These bugs shouldn't happen with clang.
> > 
> > But the global named register works slightly differently in clang. For
> > the global, the value is just the value of the register itself,
> > whatever it is. Read/write from global named register is just like
> > direct read/write to the register
> 
> Thanks, that clears up a lot of the confusion for me.
> 
> Still, unfortunately, I don't think that's going to work for GCC.
> Changing the '__sp' register variable to global in the header file
> causes it to make a *bunch* of changes across the kernel, even in
> functions which don't do inline asm.  It seems to be disabling some
> optimizations across the board.
> 
> I do have another idea, which is to replace all uses of
> 
>   asm(" ... call foo ... " : outputs : inputs : clobbers);
> 
> with a new ASM_CALL macro:
> 
>   ASM_CALL(" ... call foo ... ", outputs, inputs, clobbers);
> 
> Then the compiler differences can be abstracted out, with GCC adding
> "sp" as an output constraint and clang doing nothing (for now).

The idea sounds interesting, however I see two issues with ASM_CALL():

Inline assembly expects the individual elements of outputs, inputs and
clobbers to be comma separated, and so does the macro for it's
parameters.

The assembler template can refer to the position of output and input
operands, adding "sp" as output changes the positions of the inputs
wrt to the clang version.

Not sure how to move forward from here. Not even using an ugly #ifdef
seems to be a halfway reasonable solution, since get_user() isn't the
only place using this construct and #ifdefs would result in highly
redundant macros in multiple places.

  parent reply	other threads:[~2017-07-29  0:38 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
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 [this message]
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=20170729003852.GD84665@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=ryabinin.a.a@gmail.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 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).