linux-kernel - Re: Linux FSGSBASE testing

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] [day] [month] [year] [list]

Message-ID: <6e3d25fc-9a67-8655-a00a-b3afbc360ff0@cs.unc.edu>
Date:   Sat, 18 Jul 2020 16:18:06 -0400
From:   Don Porter <porter@...unc.edu>
To:     Andy Lutomirski <luto@...capital.net>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        Stas Sergeev <stsp@...t.ru>, linux-sgx@...r.kernel.org
Subject: Re: Linux FSGSBASE testing

On 6/20/20 11:59 AM, Andy Lutomirski wrote:
> Hi Stas-
> 
> FSGSBASE support is queued up for Linux 5.9.  Since you're one of the
> more exotic users of segmentation on Linux, is there any chance you
> could test it?  The code is here:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/fsgsbase
> 
> There are two interesting cases to test:
> 
> 1. FSGSBASE on.  This is the default if you boot this kernel on Ivy
> Bridge or newer hardware.
> 
> 2. FSGSBASE off on a patched kernel.  Boot the same kernel as in #1
> but either pass nofsgsbase on the kernel command line or use pre-Ivy
> Bridge hardware.  You will *
> 
> You can tell you have FSGSBASE enabled for test #1 by running
> tools/testing/selftests/x86/fsgsbase_64 -- the first line of output
> will be :FSGSBASE instructions are enabled".  You can build it by
> cd-ing to tools/testing/selftests/x86 and running make.
> 
> If anything is broken for you, I'd like to know before this makes it
> into a released kernel!
> 
> Thanks,
> Andy
> 

FWIW, we tested this patch using Graphene under Case 1, both in our 
standard CI pipelines, and with hand testing.  Everything looks good on 
our end - no suspicious dmesg, no application-level issues.

I also reran the stress test Andy suggested on a separate thread, which 
also looks good:
* Graphene running nginx pinned to core 0
* infinite loop on core 0
* perf top running
* Exercised with non-SGX apache bench several times (~10 minutes of 
testing time) also from core 0

All the best,
Don