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: <20200529030715.GA6182@linux.intel.com>
Date:   Fri, 29 May 2020 06:07:15 +0300
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Sasha Levin <sashal@...nel.org>
Cc:     Don Porter <porter@...unc.edu>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andi Kleen <ak@...ux.intel.com>, 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 Thu, May 28, 2020 at 03:41:57PM -0400, Sasha Levin wrote:
> On Thu, May 28, 2020 at 10:19:10PM +0300, Jarkko Sakkinen wrote:
> > On Thu, May 28, 2020 at 01:40:16PM -0400, Don Porter 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.
> > 
> > Are you going to experiment with this patch set and Graphene? Just
> > sanity checking so that I don't unnecessarily do duplicate work.
> > 
> > I ignored most of the discussion since I came here only with the
> > motivation of testing Graphene together with this patch set. I'm
> > assuming that motivation is always good no matter which angle you come
> > from. Thus, I might have missed the part I'm asking.
> 
> This series was heavily tested with Graphene-like workloads.

Is there something then readily available to test such workload with SGX
enabled? Or should I go patching Graphene? Not sure what I should take
from that comment :-)

For me the main point is that I need a tool to create arbitrary work
loads and run them inside enclave, once the SGX support reaches the
upstream. It's not just about testing this particular series.

The reason why I've been passive with this work so far is that I've been
busy combining updating of SGX series for over two years and maintaining
work. Now is the first time when I have time for this.

Actually I found this by searching lore.kernel.org whether anything has
happend with this. Have had a bullet in my backlog for ages.

/Jarkko