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;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v12 00/18] Enable FSGSBASE instructions
Date:   Thu, 28 May 2020 11:38:01 -0700
Message-Id: <7A3EBAB0-B3B3-4CB7-AA6A-FDF29D03E30D@amacapital.net>
References: <e9a0a521-104b-5c3a-a689-78f878e73d31@cs.unc.edu>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
        Andi Kleen <ak@linux.intel.com>,
        Sasha Levin <sashal@kernel.org>, linux-kernel@vger.kernel.org,
        bp@alien8.de, luto@kernel.org, hpa@zytor.com,
        dave.hansen@intel.com, tony.luck@intel.com,
        ravi.v.shankar@intel.com, chang.seok.bae@intel.com
In-Reply-To: <e9a0a521-104b-5c3a-a689-78f878e73d31@cs.unc.edu>
To:     Don Porter <porter@cs.unc.edu>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On May 28, 2020, at 10:40 AM, Don Porter <porter@cs.unc.edu> wrote:
>=20
> =EF=BB=BFHi Thomas,
>=20
> On 5/28/20 6:29 AM, Thomas Gleixner wrote:
>>> Until recently, we were doing proof-of-concept research, not product
>>> development, and there are limited hours in the day.  I also hasten to
>>> say that the product of research is an article, the software artifact
>>> serves as documentation of the experiment.  In contrast, the product of
>>> software development is software.  It takes significant time and effort
>>> to convert one to the other.  Upstreaming code is of little scientific
>>> interest.  But things have changed for our project; we had no users in
>>> 2015 and we are now un-cutting corners that are appropriate for research=

>>> but inappropriate for production.  For a research artifact with an
>>> audience that knew the risks, we shipped a module because it was easier
>>> to maintain and install than a kernel patch.
>> I understand that and with a big fat warning and documentation from
>> start I wouldn't have complained so vehemently.
>=20
> This is a fair point.  We will fix this ASAP, and I will be more careful a=
bout this going forward.
>=20
>>=20
>> Sorry for that innuendo. Now that my anger and general frustration about
>> this whole disaster have calmed down, I surely would not write that
>> again.
>=20
> I appreciate you saying so.  Thank you.
>=20
> I can also understand how frustrating the history was with this feature, a=
nd we missed an opportunity to help sooner.  There is a lot I still don't un=
derstand about the process of merging and testing patches in this community,=
 but if it makes sense for us to help now, we would be willing.
>=20
>=20

With my x86 hat on, I have no particular expectation that you would be famil=
iar with the particular problems wi TV FSGSBASE. One sequence that will kill=
 the kernel is to use WRGSBASE to load a negative value (e.g. ~0), then set E=
FLAGS.TF and do SYSENTER. I=E2=80=99m adding a test like this to the x86 sel=
ftests.

One useful test for the actual kernel patches would be to run your SGX workl=
oad on a loaded core.  That is, do
something like taskset -c 0 graphene_thing and, simultaneously, write a triv=
ial infinite loop program and run that under taskset -c 0 as well. For good m=
easure, you could have perf top or perf record running at the same time.  Lo=
ok for kernel errors, but also look for any evidence of your workload malfun=
ctioning.

=E2=80=94Andy=