MIME-Version: 1.0
In-Reply-To: <20150427183854.GG28871@pd.tnic>
References: <5d120f358612d73fc909f5bfa47e7bd082db0af0.1429841474.git.luto@kernel.org>
	<20150425211206.GE32099@pd.tnic>
	<CALCETrWvqyCYOzCYXz7ZnzaM0obbidqo5CxVp2Hn1ELEiC3m3g@mail.gmail.com>
	<20150427085305.GB6774@pd.tnic>
	<20150427113506.GG6774@pd.tnic>
	<CA+55aFykNBrdHFSVeLftG7Ujx4Tk=MuUJXD2rNYn9kwL+kLN5w@mail.gmail.com>
	<20150427154631.GB28871@pd.tnic>
	<CA+55aFxWyhc+ax_jnqH9zsvqruL63gcePMbRQGJ_wM06e1QKpA@mail.gmail.com>
	<20150427164024.GD28871@pd.tnic>
	<CA+55aFySbPjeCgetxeSQPSP-h+yKnrHPcTGuoorAHJbCj53-8A@mail.gmail.com>
	<20150427183854.GG28871@pd.tnic>
Date: Mon, 27 Apr 2015 11:47:30 -0700
Message-ID: <CA+55aFzYz=b887TLTuJ1u6Fv3B0eeXtnx+XzojJ8BBqm+Eha_g@mail.gmail.com>
Subject: Re: [PATCH] x86_64, asm: Work around AMD SYSRET SS descriptor
 attribute issue
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>, Andy Lutomirski <luto@kernel.org>,
        X86 ML <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
        Denys Vlasenko <vda.linux@googlemail.com>,
        Brian Gerst <brgerst@gmail.com>, Denys Vlasenko <dvlasenk@redhat.com>,
        Ingo Molnar <mingo@kernel.org>, Steven Rostedt <rostedt@goodmis.org>,
        Oleg Nesterov <oleg@redhat.com>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Alexei Starovoitov <ast@plumgrid.com>, Will Drewry <wad@chromium.org>,
        Kees Cook <keescook@chromium.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1077
Lines: 27

On Mon, Apr 27, 2015 at 11:38 AM, Borislav Petkov <bp@alien8.de> wrote:
>
> So our current NOP-infrastructure does ASM_NOP_MAX NOPs of 8 bytes so
> without more invasive changes, our longest NOPs are 8 byte long and then
> we have to repeat.

Btw (and I'm too lazy to check) do we take alignment into account?

Because if you have to split, and use multiple nops, it is *probably*
a good idea to try to avoid 16-byte boundaries, since that's can be
the I$ fetch granularity from L1 (although I guess 32B is getting more
common).

So the exact split might depend on the alignment of the nop replacement..

> You can recognize the p6_nops being the same as in-the-manual-suggested
> F16h ones.

Can we perhaps get rid of the distinction entirely, and just use one
set of 64-bit nops for both Intel/AMD?

                        Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/