mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Andi Kleen <ak@linux.intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	"Bae, Chang Seok" <chang.seok.bae@intel.com>,
	"Metzger, Markus T" <markus.t.metzger@intel.com>,
	"hpa@zytor.com" <hpa@zytor.com>, "bp@alien8.de" <bp@alien8.de>,
	"Hansen, Dave" <dave.hansen@intel.com>,
	"Luck, Tony" <tony.luck@intel.com>,
	Pedro Alves <palves@redhat.com>, Simon Marchi <simark@simark.ca>,
	"Shankar, Ravi V" <ravi.v.shankar@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v9 00/17] Enable FSGSBASE instructions
Date: Tue, 21 Apr 2020 12:06:22 -0400	[thread overview]
Message-ID: <20200421160622.GJ1809@sasha-vm> (raw)
In-Reply-To: <87y2qqaxkp.fsf@nanos.tec.linutronix.de>

On Mon, Apr 20, 2020 at 07:14:46PM +0200, Thomas Gleixner wrote:
>Andi Kleen <ak@linux.intel.com> writes:
>>> the *gdb developers* don't care.  But gdb isn't exactly a good example
>>> of a piece of software that tries to work correctly when dealing with
>>> unusual software.  Maybe other things like rr will care more.  It
>>
>> rr is used to replay modern software, and modern software
>> doesn't care about selectors, thus rr doesn't care either.
>>
>> Please stop the FUD.
>
>There is absolutely no FUD. Being careful about not breaking existing
>user space is a legitimate request.
>
>It's up to those who change the ABI to prove that it does not matter and
>not up to the maintainers to figure it out.

I think that this is a difficult ask; "prove that god doesn't exist".

Andi's point is that there is no known user it breaks, and the Intel
folks did some digging into potential users who might be affected by
this, including 'rr' brought up by Andy, and concluded that there won't
be breakage as a result of this patchset:

	https://mail.mozilla.org/pipermail/rr-dev/2018-March/000616.html

Sure, if you poke at it you could see a behavior change, but is there
an actual user that will be affected by it? I suspect not.

>This sits in limbo for months now just because Intel doesn't get it's
>homework done.
>
>Stop making false accusations and provide factual information instead.

If there's no known user that will be broken here, can we consider
merging this to be disabled by default and let distros try it out? This
will let us find these users while providing an easy way to work around
the problem.

-- 
Thanks,
Sasha

  reply	other threads:[~2020-04-21 16:06 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-04 18:15 Chang S. Bae
2019-10-04 18:15 ` [PATCH v9 01/17] x86/ptrace: Prevent ptrace from clearing the FS/GS selector Chang S. Bae
2019-10-04 18:15 ` [PATCH v9 02/17] selftests/x86/fsgsbase: Test GS selector on ptracer-induced GS base write Chang S. Bae
2019-10-04 18:15 ` [PATCH v9 03/17] x86/cpu: Add 'unsafe_fsgsbase' to enable CR4.FSGSBASE Chang S. Bae
2019-10-04 18:15 ` [PATCH v9 04/17] x86/entry/64: Clean up paranoid exit Chang S. Bae
2019-10-04 18:15 ` [PATCH v9 05/17] x86/entry/64: Switch CR3 before SWAPGS in paranoid entry Chang S. Bae
2019-10-04 18:15 ` [PATCH v9 06/17] x86/entry/64: Introduce the FIND_PERCPU_BASE macro Chang S. Bae
2019-10-04 18:15 ` [PATCH v9 07/17] x86/entry/64: Handle FSGSBASE enabled paranoid entry/exit Chang S. Bae
2019-10-04 18:16 ` [PATCH v9 08/17] x86/entry/64: Document GSBASE handling in the paranoid path Chang S. Bae
2019-10-04 18:16 ` [PATCH v9 09/17] x86/fsgsbase/64: Add intrinsics for FSGSBASE instructions Chang S. Bae
2019-10-04 18:16 ` [PATCH v9 10/17] x86/fsgsbase/64: Enable FSGSBASE instructions in helper functions Chang S. Bae
2019-10-04 18:16 ` [PATCH v9 11/17] x86/fsgsbase/64: Use FSGSBASE in switch_to() if available Chang S. Bae
2019-10-04 18:16 ` [PATCH v9 12/17] x86/fsgsbase/64: Use FSGSBASE instructions on thread copy and ptrace Chang S. Bae
2019-10-04 18:16 ` [PATCH v9 13/17] x86/speculation/swapgs: Check FSGSBASE in enabling SWAPGS mitigation Chang S. Bae
2019-10-04 18:16 ` [PATCH v9 14/17] selftests/x86/fsgsbase: Test ptracer-induced GS base write with FSGSBASE Chang S. Bae
2019-10-04 18:16 ` [PATCH v9 15/17] x86/fsgsbase/64: Enable FSGSBASE on 64bit by default and add a chicken bit Chang S. Bae
2019-10-04 18:16 ` [PATCH v9 16/17] x86/elf: Enumerate kernel FSGSBASE capability in AT_HWCAP2 Chang S. Bae
2019-10-04 18:16 ` [PATCH v9 17/17] Documentation/x86/64: Add documentation for GS/FS addressing mode Chang S. Bae
2019-10-04 22:54   ` Randy Dunlap
2019-11-15 18:29 ` [PATCH v9 00/17] Enable FSGSBASE instructions Thomas Gleixner
2019-11-15 19:12   ` Andi Kleen
2019-11-29 14:56     ` Metzger, Markus T
2019-11-29 16:51       ` Andy Lutomirski
2019-12-02  8:23         ` Metzger, Markus T
2019-12-04 20:20           ` Andy Lutomirski
2019-12-10  8:27             ` Metzger, Markus T
2020-02-24 18:02             ` Bae, Chang Seok
2020-04-13 20:03               ` Sasha Levin
2020-04-14  0:32                 ` Andi Kleen
2020-04-17 13:30                   ` Sasha Levin
2020-04-17 15:52                     ` Andy Lutomirski
2020-04-20 14:13                       ` Andi Kleen
2020-04-20 17:14                         ` Thomas Gleixner
2020-04-21 16:06                           ` Sasha Levin [this message]
2020-04-21 16:49                             ` Andy Lutomirski
2020-04-21 20:02                               ` Andi Kleen
2020-04-21 17:15                             ` Bae, Chang Seok
2020-04-21 19:56                             ` Andi Kleen
2020-04-21 20:21                               ` Andy Lutomirski
2020-04-21 20:51                                 ` Sasha Levin
2020-04-22 23:00                                   ` Andy Lutomirski
2020-04-23  4:08                                     ` Sasha Levin
2020-04-25 22:39                                       ` Thomas Gleixner
2020-04-26  2:52                                         ` Sasha Levin
2020-04-26 10:04                                           ` Thomas Gleixner
2020-04-14 15:47                 ` Bae, Chang Seok

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=20200421160622.GJ1809@sasha-vm \
    --to=sashal@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=chang.seok.bae@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=markus.t.metzger@intel.com \
    --cc=palves@redhat.com \
    --cc=ravi.v.shankar@intel.com \
    --cc=simark@simark.ca \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    /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

Powered by JetHome