linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Quentin Casasnovas <quentin.casasnovas@oracle.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>,
	X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Oleg Nesterov <oleg@redhat.com>,
	Andy Lutomirski <luto@amacapital.net>
Subject: Re: [PATCH] x86/xsave: Robustify and merge macros
Date: Fri, 3 Apr 2015 16:06:30 +0200	[thread overview]
Message-ID: <20150403140630.GD14902@chrystal.uk.oracle.com> (raw)
In-Reply-To: <20150402161259.GE3483@pd.tnic>

On Thu, Apr 02, 2015 at 06:12:59PM +0200, Borislav Petkov wrote:
> On Thu, Apr 02, 2015 at 05:52:10PM +0200, Quentin Casasnovas wrote:
> > I've tried compiling this on top of v4.0-rc5 and I get a compile error
> > because alt_end_marker isn't defined.  Which other patches should I take to
> > test this?
> 
> It needs tip/master.
>

So I've had a look at tip/master and I don't _think_ commit

   4332195 ("x86/alternatives: Add instruction padding")

is correct.

> +.macro ALTERNATIVE_2 oldinstr, newinstr1, feature1, newinstr2, feature2
> +140:
> +       \oldinstr
> +141:
> +       .skip -(((144f-143f)-(141b-140b)) > 0) * ((144f-143f)-(141b-140b)),0x90
> +       .skip -(((145f-144f)-(144f-143f)-(141b-140b)) > 0) * ((145f-144f)-(144f-143f)-(141b-140b)),0x90

I'm missing how the second .skip directive is supposed to work.  For
example, assuming:

 sizeof(repl2)   = (145f-144f) = 5 and
 sizeof(repl1)   = (144f-143f) = 4 and
 sizeof(oldinsn) = (141b-140b) = 3

it'll do:

=>  .skip -(((5) - (4) - (3)) > 0) * ((5) - (4) -(3)), 0x90
=>  .skip -((-2) > 0) * (-2), 0x90
=>  .skip 0*-2, 0x90 ; we're not skipping anything here are we?
=>  .skip 0, 0x90

Whereas AIUI, we were supposed to have skipped another extra byte: the
original instruction is 3 bytes long, and we added one NOP byte in the
first .skip directive because repl1 was 4 bytes, and we're not adding the
remaining one byte needed to apply repl2.  Provided this is correct and I'm
not missing something, the ALTERNATIVE_2() macro defined in
asm/alternative.h is suffering from the same problem.

I think we want to substract to sizeof(repl2) the _max_ between
sizeof(repl1) and sizeof(oldinsn), so it would probably look something like
this horrible line:

.skip -(((145f - 144f) - max((144f - 143f), (141b - 140b))) > 0) *
      	((145f - 144f) - max((144f - 143f), (141b - 140b))), 0x90

And if we can't really use max(a,b) here, we can use something like this
even more horrible line:

.skip -(((145f - 144f) - ((-(((144f - 143f) - (141b - 140b)) >  0) * (144f - 143f))  +
      	       	       	  (-(((144f - 143f) - (141b - 140b)) <= 0) * (141b - 143b)))) > 0) *
        ((145f - 144f) - ((-(((144f - 143f) - (141b - 140b)) >  0) * (144f - 143f))  +
      	       	       	  (-(((144f - 143f) - (141b - 140b)) <= 0) * (141b - 143b))))

This is obviously completely un-tested and not even compiled! :)

Now that I think about it though, can we not make use of the .if directive
to make the two .skip directives much easier to parse?  That question
applies even more if your original code is correct and I missed something
above, since I'd blame the un-readability to explain my misunderstanding :P

e.g.

#define size_orig_insn  (141b - 140b)
#define size_repl1      (144f - 143f)
#define size_repl2      (145f - 144f)

.macro PAD_ALTERNATIVE_1
       ; Pad with NOP if orig_insn is smaller than repl1
        .if (size_repl1 > size_orig_insn)
                .skip size_repl1 - size_orig_insn, 0x90
        .endif
.endmacro

.macro PAD_ALTERNATIVE_2
	PAD_ALTERNATIVE_1

        ; Pad with NOP if orig_insn + above padding is smaller than repl2
        .if ((size_repl2 > size_repl1) || (size_repl2 > size_orig_insn))
                .if (size_repl1 > size_orig_insn)
                        .skip size_repl2 - size_repl1, 0x90
                .else
                        .skip size_repl2 - size_orig_insn, 090
                .endif
        .endif
.endmacro

.macro ALTERNATIVE_2 oldinstr, newinstr1, feature1, newinstr2, feature2
140:
       \oldinstr
141:
	PAD_ALTERNATIVE_2
	...

Again this is un-tested so maybe it's not possible to do it this way.  What
do you think?

Quentin

  parent reply	other threads:[~2015-04-03 14:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-02 13:11 [PATCH] x86/xsave: Robustify and merge macros Borislav Petkov
2015-04-02 15:52 ` Quentin Casasnovas
2015-04-02 16:12   ` Borislav Petkov
2015-04-02 16:33     ` Quentin Casasnovas
2015-04-02 16:45       ` Borislav Petkov
2015-04-03 14:06     ` Quentin Casasnovas [this message]
2015-04-03 14:14       ` Quentin Casasnovas
2015-04-03 15:23         ` Borislav Petkov
2015-04-03 15:40           ` Quentin Casasnovas
2015-04-03 17:06             ` Borislav Petkov
2015-04-03 17:33               ` Quentin Casasnovas
2015-04-03 17:48                 ` Borislav Petkov
2015-04-03 20:42                   ` Quentin Casasnovas
2015-04-04  7:34                     ` Borislav Petkov
2015-04-04  8:36                       ` Quentin Casasnovas
2015-04-04  9:25                         ` Borislav Petkov
2015-04-04 10:11                           ` Quentin Casasnovas
2015-04-04 10:29                             ` Borislav Petkov
2015-04-04 13:32                               ` Borislav Petkov
2015-04-04 13:34                                 ` [PATCH] x86/alternatives: Fix ALTERNATIVE_2 padding generation properly Borislav Petkov
2015-04-07  9:27                                   ` Quentin Casasnovas
2015-04-07  9:40                                   ` [tip:x86/asm] " tip-bot for Borislav Petkov

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=20150403140630.GD14902@chrystal.uk.oracle.com \
    --to=quentin.casasnovas@oracle.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.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).