From: "Bae, Chang Seok" <chang.seok.bae@intel.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: X86 ML <x86@kernel.org>, Andi Kleen <ak@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"Metzger, Markus T" <markus.t.metzger@intel.com>,
"Luck, Tony" <tony.luck@intel.com>,
"Shankar, Ravi V" <ravi.v.shankar@intel.com>,
LKML <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: Tue, 20 Mar 2018 16:33:42 +0000 [thread overview]
Message-ID: <B96DA962-6278-4FDE-A8C6-020E789CE67F@intel.com> (raw)
In-Reply-To: <CALCETrXes+XRLWQfKO+jmzyTAxncZAm0WReuKFvNDcFGERqyeA@mail.gmail.com>
On 3/20/18, 07:58, "Andy Lutomirski" <luto@kernel.org> wrote:
>> On Mar 19, 2018, at 10:49 AM, Chang S. Bae <chang.seok.bae@intel.com> wrote:
>>
>> When FSGSBASE is enabled, SWAPGS needs if and only if (current)
>> GS base is not the kernel's.
>>
>> FSGSBASE instructions allow user to write any value on GS base;
>> even negative. Sign check on the current GS base is not
>> sufficient. Fortunately, reading GS base is fast. Kernel GS
>> base is also known from the offset table with the CPU number.
> The original version of these patches (mine and Andi’s) didn’t have
> this comparison, didn’t need RDMSR, and didn’t allow malicious user
> programs to cause the kernel to run decently large chunks of code with
> the reverse of the expected GS convention. Why did you change it?
> I really really don't like having a corner case like this that can and
> will be triggered by malicious user code but that is hard to write a
> self-test for because it involves guessing a 64-bit magic number.
> Untestable corner cases in the x86 entry code are bad.
Originally, I took it. But since it keeps kernel GS base on the (IST) stack,
it is thought as fragile [1] AFAIK. If you really don't like this "comparison"
then GS base can be written (unconditionally) while the original GS
base stitched (like the original approach did) IMO.
[1] https://marc.info/?l=linux-kernel&m=151725088506036&w=3
next prev parent reply other threads:[~2018-03-20 16:33 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
2018-03-20 14:58 ` Andy Lutomirski
2018-03-20 16:33 ` Bae, Chang Seok [this message]
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=B96DA962-6278-4FDE-A8C6-020E789CE67F@intel.com \
--to=chang.seok.bae@intel.com \
--cc=ak@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.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).