linux-kernel - Re: [PATCH v12 00/18] Enable FSGSBASE instructions

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <7A3EBAB0-B3B3-4CB7-AA6A-FDF29D03E30D@amacapital.net>
Date:   Thu, 28 May 2020 11:38:01 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Don Porter <porter@...unc.edu>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Sasha Levin <sashal@...nel.org>, linux-kernel@...r.kernel.org,
        bp@...en8.de, luto@...nel.org, hpa@...or.com,
        dave.hansen@...el.com, tony.luck@...el.com,
        ravi.v.shankar@...el.com, chang.seok.bae@...el.com
Subject: Re: [PATCH v12 00/18] Enable FSGSBASE instructions



> On May 28, 2020, at 10:40 AM, Don Porter <porter@...unc.edu> wrote:
> 
> Hi Thomas,
> 
> 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.
> 
> This is a fair point.  We will fix this ASAP, and I will be more careful about this going forward.
> 
>> 
>> 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.
> 
> I appreciate you saying so.  Thank you.
> 
> I can also understand how frustrating the history was with this feature, and we missed an opportunity to help sooner.  There is a lot I still don't understand 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.
> 
> 

With my x86 hat on, I have no particular expectation that you would be familiar 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 EFLAGS.TF and do SYSENTER. I’m adding a test like this to the x86 selftests.

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

—Andy