From: "H. Peter Anvin" <hpa@zytor.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: David Laight <David.Laight@aculab.com>,
"Chang S. Bae" <chang.seok.bae@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"ak@linux.intel.com" <ak@linux.intel.com>,
"markus.t.metzger@intel.com" <markus.t.metzger@intel.com>,
"tony.luck@intel.com" <tony.luck@intel.com>,
"ravi.v.shankar@intel.com" <ravi.v.shankar@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCH 13/15] x86/fsgsbase/64: With FSGSBASE, compare GS bases on paranoid_entry
Date: Wed, 21 Mar 2018 14:56:23 -0700 [thread overview]
Message-ID: <9aa3ef0a-84b5-9806-4213-1b63023e6c5a@zytor.com> (raw)
In-Reply-To: <CALCETrX0ew6xcbxiKDkpGw8CJsF0TWNZc=GHuVEPbDpfZ-X3ww@mail.gmail.com>
On 03/20/18 17:36, Andy Lutomirski wrote:
>>
>> But we also don't need swapgs when we have rdgsbase/wrgsbase available.
>> We can indeed just unconditionally save it (via rdgsbase) into the stack
>> frame and wrgsbase the correct percpu value. In that case it might be
>> necessary in order to avoid insane complexity to also save/restore the
>> gs selector.
>
> This is exactly what the old code did. I liked the old code better.
>
>>
>> Is it going to be faster? *Probably* not as swapgs is designed to be
>> fast; it does, however, eliminate the need to RDMSR/WRMSR inside the
>> kernel task switch as the user space gsbase will simply live on the
>> stack. (This is assuming we do this unconditionally on every method of
>> kernel entry, including non-paranoid. I'm not sure if we ever care
>> about the userspace GS/GSBASE inside a paranoid handler, but if we do it
>> would be rather messy to find if we do this conditionally.
>>
>> Now...
>>
>> + ALTERNATIVE "jmp .Lparanoid_entry_no_fsgsbase", \
>> + "RDGSBASE %rdx", X86_FEATURE_FSGSBASE
>> + READ_KERNEL_GSBASE %rax
>>
>> READ_KERNEL_GSBASE here seems like a Really Bad Name[TM] for this macro,
>> since it seems to imply reading MSR_KERNEL_GS_BASE, rather than finding
>> the current percpu offset. I would prefer calling it something like
>> FIND_PERCPU_BASE or something like that.
>
> I think we should revert to what the old patches did here.
>
I don't really understand why you want to do it this way.
1. It means that the location of the user space gs_base is ill-defined,
whereas with the SWAPGS it is *always* in the same place.
2. It is most likely slower, although I obviously haven't benchmarked
it.
-hpa
next prev parent reply other threads:[~2018-03-21 21:56 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-19 17:49 [PATCH 00/15] x86: Enable FSGSBASE instructions Chang S. Bae
2018-03-19 17:49 ` [PATCH 01/15] x86/fsgsbase/64: Introduce FS/GS base helper functions Chang S. Bae
2018-03-19 17:49 ` [PATCH 02/15] x86/fsgsbase/64: Make ptrace read FS/GS base accurately Chang S. Bae
2018-03-19 17:49 ` [PATCH 03/15] x86/fsgsbase/64: Use FS/GS base helpers in core dump Chang S. Bae
2018-03-19 17:49 ` [PATCH 04/15] x86/fsgsbase/64: Factor out load FS/GS segments from __switch_to Chang S. Bae
2018-03-19 17:49 ` [PATCH 05/15] x86/ptrace: A new macro to get an offset of user_regs_struct Chang S. Bae
2018-03-19 17:49 ` [PATCH 06/15] x86/fsgsbase/64: Add putregs() to handle multiple elements' setting Chang S. Bae
2018-03-19 17:49 ` [PATCH 07/15] x86/fsgsbase/64: putregs() in a reverse order Chang S. Bae
2018-03-19 17:49 ` [PATCH 08/15] x86/fsgsbase/64: Add 'unsafe_fsgsbase' to enable CR4.FSGSBASE Chang S. Bae
2018-03-19 17:49 ` [PATCH 09/15] x86/fsgsbase/64: Add intrinsics/macros for FSGSBASE instructions Chang S. Bae
2018-03-19 17:49 ` [PATCH 10/15] x86/fsgsbase/64: Enable FSGSBASE instructions in helper functions Chang S. Bae
2018-03-19 17:49 ` [PATCH 11/15] x86/fsgsbase/64: Preserve FS/GS state in __switch_to if FSGSBASE is on Chang S. Bae
2018-03-19 17:49 ` [PATCH 12/15] x86/fsgsbase/64: When copying a thread, use FSGSBASE if enabled Chang S. Bae
2018-03-19 17:49 ` [PATCH 13/15] x86/fsgsbase/64: With FSGSBASE, compare GS bases on paranoid_entry Chang S. Bae
2018-03-19 20:05 ` Dave Hansen
2018-03-19 21:12 ` Bae, Chang Seok
2018-03-20 10:16 ` David Laight
2018-03-20 20:07 ` H. Peter Anvin
2018-03-20 20:36 ` Bae, Chang Seok
2018-03-21 0:36 ` Andy Lutomirski
2018-03-21 21:56 ` H. Peter Anvin [this message]
2018-03-20 14:58 ` Andy Lutomirski
2018-03-20 16:33 ` Bae, Chang Seok
2018-03-20 17:03 ` Bae, Chang Seok
2018-03-21 22:03 ` H. Peter Anvin
2018-03-22 1:37 ` Andy Lutomirski
2018-03-19 17:49 ` [PATCH 14/15] x86/fsgsbase/64: Support legacy behavior when FS/GS updated by ptracer Chang S. Bae
2018-03-20 15:04 ` Andy Lutomirski
2018-03-20 16:33 ` Bae, Chang Seok
2018-03-21 0:47 ` Andy Lutomirski
2018-03-21 7:01 ` Metzger, Markus T
2018-03-22 1:39 ` Andy Lutomirski
2018-03-21 15:11 ` Bae, Chang Seok
2018-03-22 1:40 ` Andy Lutomirski
2018-03-22 15:45 ` Bae, Chang Seok
2018-03-22 16:07 ` Andy Lutomirski
2018-03-22 16:46 ` Bae, Chang Seok
2018-03-22 16:53 ` Andy Lutomirski
2018-03-22 21:17 ` Bae, Chang Seok
2018-03-22 21:28 ` Andy Lutomirski
2018-03-19 17:49 ` [PATCH 15/15] x86/fsgsbase/64: Enable FSGSBASE by default and add a chicken bit Chang S. Bae
2018-03-20 15:05 ` [PATCH 00/15] x86: Enable FSGSBASE instructions Andy Lutomirski
2018-03-20 15:06 ` Andy Lutomirski
2018-03-20 16:33 ` Bae, Chang Seok
2018-03-21 0:40 ` Andy Lutomirski
2018-03-21 15:15 ` 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=9aa3ef0a-84b5-9806-4213-1b63023e6c5a@zytor.com \
--to=hpa@zytor.com \
--cc=David.Laight@aculab.com \
--cc=ak@linux.intel.com \
--cc=chang.seok.bae@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=markus.t.metzger@intel.com \
--cc=ravi.v.shankar@intel.com \
--cc=tony.luck@intel.com \
--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).