Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: Linux FSGSBASE testing
To:     Andy Lutomirski <luto@amacapital.net>,
        LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
        Stas Sergeev <stsp@list.ru>, linux-sgx@vger.kernel.org
References: <CALCETrU_O4AxcJeBO77uXt2j8woYVtjZd18-YV0BuCKRAu00eA@mail.gmail.com>
From:   Don Porter <porter@cs.unc.edu>
Message-ID: <6e3d25fc-9a67-8655-a00a-b3afbc360ff0@cs.unc.edu>
Date:   Sat, 18 Jul 2020 16:18:06 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0)
 Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CALCETrU_O4AxcJeBO77uXt2j8woYVtjZd18-YV0BuCKRAu00eA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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