kernel-hardening.lists.openwall.com archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch@vger.kernel.org, Andi Kleen <ak@linux.intel.com>,
	Kees Cook <keescook@chromium.org>,
	kernel-hardening@lists.openwall.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Al Viro <viro@zeniv.linux.org.uk>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alan Cox <alan@linux.intel.com>
Subject: [kernel-hardening] Re: [PATCH v3 8/9] x86: use __uaccess_begin_nospec and ASM_IFENCE in get_user paths
Date: Sat, 13 Jan 2018 14:22:17 -0600	[thread overview]
Message-ID: <87inc5zeyu.fsf@xmission.com> (raw)
In-Reply-To: <CA+55aFxsg5+u7bCHj1N8xyyVf7-RMm-5ACNp=ENNrKL78omaow@mail.gmail.com> (Linus Torvalds's message of "Sat, 13 Jan 2018 11:33:50 -0800")

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Sat, Jan 13, 2018 at 11:05 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> I _know_ that lfence is expensive as hell on P4, for example.
>>
>> Yes, yes, "sbb" is often more expensive than most ALU instructions,
>> and Agner Fog says it has a 10-cycle latency on Prescott (which is
>> outrageous, but being one or two cycles more due to the flags
>> generation is normal). So the sbb/and may certainly add a few cycles
>> to the critical path, but on Prescott "lfence" is *50* cycles
>> according to those same tables by Agner Fog.
>
> Side note: I don't think P4 is really relevant for a performance
> discussion, I was just giving it as an example where we do know actual
> cycles.
>
> I'm much more interested in modern Intel big-core CPU's, and just
> wondering whether somebody could ask an architect.
>
> Because I _suspect_ the answer from a CPU architect would be: "Christ,
> the sbb/and sequence is much better because it doesn't have any extra
> serialization", but maybe I'm wrong, and people feel that lfence is
> particularly easy to do right without any real downside.

As an educated observer it seems like the cmpq/sbb/and sequence is an
improvement because it moves the dependency from one end of the cpu
pipeline to another.  If any cpu does data speculation on anything other
than branch targets that sequence could still be susceptible to
speculation.

>From the AMD patches it appears that lfence is becoming a serializing
instruction which in principal is much more expensive.

Also do we have alternatives for these sequences so if we run on an
in-order atom (or 386 or 486) where speculation does not occur we can
avoid the cost?

Eric

  reply	other threads:[~2018-01-13 20:22 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-13 18:17 [kernel-hardening] [PATCH v3 0/9] core, x86: prevent bounds-check bypass via speculative execution Dan Williams
2018-01-13 18:17 ` [kernel-hardening] [PATCH v3 1/9] Documentation: document array_ptr Dan Williams
2018-01-13 18:17 ` [kernel-hardening] [PATCH v3 2/9] arm64: implement ifence_array_ptr() Dan Williams
2018-01-13 18:17 ` [kernel-hardening] [PATCH v3 3/9] arm: " Dan Williams
2018-01-13 18:17 ` [kernel-hardening] [PATCH v3 4/9] x86: implement ifence() Dan Williams
2018-01-13 18:17 ` [kernel-hardening] [PATCH v3 5/9] x86: implement ifence_array_ptr() and array_ptr_mask() Dan Williams
2018-01-13 18:17 ` [kernel-hardening] [PATCH v3 6/9] asm/nospec: mask speculative execution flows Dan Williams
2018-01-13 18:18 ` [kernel-hardening] [PATCH v3 7/9] x86: introduce __uaccess_begin_nospec and ASM_IFENCE Dan Williams
2018-01-13 18:18 ` [kernel-hardening] [PATCH v3 8/9] x86: use __uaccess_begin_nospec and ASM_IFENCE in get_user paths Dan Williams
2018-01-13 19:05   ` [kernel-hardening] " Linus Torvalds
2018-01-13 19:33     ` Linus Torvalds
2018-01-13 20:22       ` Eric W. Biederman [this message]
2018-01-16 22:23       ` Dan Williams
     [not found]         ` <CA+55aFxAFG5czVmCyhYMyHmXLNJ7pcXxWzusjZvLRh_qTGHj6Q@mail.gmail.com>
2018-01-16 22:41           ` Linus Torvalds
2018-01-17 14:17             ` Alan Cox
2018-01-17 18:52               ` Al Viro
2018-01-17 19:54                 ` Dan Williams
2018-01-17 20:05                   ` Al Viro
2018-01-17 20:14                     ` Dan Williams
2018-01-18  3:06                 ` [kernel-hardening] [RFC][PATCH] get rid of the use of set_fs() (by way of kernel_recvmsg()) in sunrpc Al Viro
2018-01-18  3:16                   ` [kernel-hardening] " Linus Torvalds
2018-01-18  4:43                     ` Al Viro
2018-01-18 16:29                       ` Christoph Hellwig
2018-01-18 17:10                         ` Al Viro
2018-01-18 19:31                       ` Al Viro
2018-01-18 20:33                         ` Al Viro
2018-01-19  3:27                         ` Al Viro
2018-01-17 19:26               ` [kernel-hardening] Re: [PATCH v3 8/9] x86: use __uaccess_begin_nospec and ASM_IFENCE in get_user paths Linus Torvalds
2018-01-17 20:01                 ` Eric Dumazet
2018-01-18 16:38                 ` Christoph Hellwig
2018-01-18 16:49                   ` Linus Torvalds
2018-01-18 18:12                     ` Al Viro
2018-01-17  4:30         ` Dan Williams
2018-01-17  6:28           ` Al Viro
2018-01-17  6:50             ` Dan Williams
2018-01-17 10:07               ` [kernel-hardening] " David Laight
2018-01-17 18:12               ` [kernel-hardening] " Dan Williams
2018-01-17 19:16           ` Linus Torvalds
2018-01-13 18:18 ` [kernel-hardening] [PATCH v3 9/9] vfs, fdtable: prevent bounds-check bypass via speculative execution Dan Williams

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=87inc5zeyu.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@linux.intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --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).