linux-kernel - Re: [PATCH 13/15] x86/fsgsbase/64: With FSGSBASE, compare GS bases on paranoid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cc9b0ef1-79c6-7a21-dc70-6f922ec45db4@zytor.com>
Date:   Wed, 21 Mar 2018 15:03:28 -0700
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Andy Lutomirski <luto@...nel.org>,
        "Chang S. Bae" <chang.seok.bae@...el.com>
Cc:     X86 ML <x86@...nel.org>, Andi Kleen <ak@...ux.intel.com>,
        "Metzger, Markus T" <markus.t.metzger@...el.com>,
        Tony Luck <tony.luck@...el.com>,
        "Ravi V. Shankar" <ravi.v.shankar@...el.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH 13/15] x86/fsgsbase/64: With FSGSBASE, compare GS bases on
 paranoid_entry

On 03/20/18 07:58, Andy Lutomirski wrote:
>> On Mar 19, 2018, at 10:49 AM, Chang S. Bae <chang.seok.bae@...el.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.
> 

What corner case are you talking about?

If user GS_BASE and kernel GS_BASE happen to be identical, then SWAPGS
is a nop and it does not matter one iota which is is user space and
which is kernel space.  They are just numbers, and swapping one number
with itself doesn't do anything (in fact, opcode 0x90 was used for NOP
because it aliased to xchg [e]ax,[e]ax on pre-64-bit hardware.)

As far as running "decently large chunks" this is *exactly* the same
amount of code that is run on non-FSGSBASE hardware, so it Has To
Work[TM] anyway.  If anything this may help catch problems sooner.

This minimizes the difference between the FSGSBASE and non-FSGSBASE
flows, which I would consider a significant win.

	-hpa