From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Sasha Levin <sashal@kernel.org>
Cc: Don Porter <porter@cs.unc.edu>,
Thomas Gleixner <tglx@linutronix.de>,
Andi Kleen <ak@linux.intel.com>,
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
Subject: Re: [PATCH v12 00/18] Enable FSGSBASE instructions
Date: Fri, 29 May 2020 06:07:15 +0300 [thread overview]
Message-ID: <20200529030715.GA6182@linux.intel.com> (raw)
In-Reply-To: <20200528194157.GB1407771@sasha-vm>
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
next prev parent reply other threads:[~2020-05-29 3:07 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-11 4:52 [PATCH v12 00/18] Enable FSGSBASE instructions Sasha Levin
2020-05-11 4:52 ` [PATCH v12 01/18] x86/ptrace: Prevent ptrace from clearing the FS/GS selector Sasha Levin
2020-05-11 4:52 ` [PATCH v12 02/18] selftests/x86/fsgsbase: Test GS selector on ptracer-induced GS base write Sasha Levin
2020-05-11 4:52 ` [PATCH v12 03/18] x86/cpu: Add 'unsafe_fsgsbase' to enable CR4.FSGSBASE Sasha Levin
2020-05-11 4:52 ` [PATCH v12 04/18] x86/entry/64: Clean up paranoid exit Sasha Levin
2020-05-11 4:52 ` [PATCH v12 05/18] x86/entry/64: Switch CR3 before SWAPGS in paranoid entry Sasha Levin
2020-05-11 4:52 ` [PATCH v12 06/18] x86/entry/64: Introduce the FIND_PERCPU_BASE macro Sasha Levin
2020-05-11 4:53 ` [PATCH v12 07/18] x86/entry/64: Handle FSGSBASE enabled paranoid entry/exit Sasha Levin
2020-05-11 4:53 ` [PATCH v12 08/18] x86/entry/64: Document GSBASE handling in the paranoid path Sasha Levin
2020-05-11 4:53 ` [PATCH v12 09/18] x86/fsgsbase/64: Add intrinsics for FSGSBASE instructions Sasha Levin
2020-05-11 4:53 ` [PATCH v12 10/18] x86/fsgsbase/64: Enable FSGSBASE instructions in helper functions Sasha Levin
2020-05-18 18:20 ` Thomas Gleixner
2020-05-18 20:24 ` Sasha Levin
2020-05-18 22:59 ` Thomas Gleixner
2020-05-19 12:20 ` David Laight
2020-05-19 14:48 ` Thomas Gleixner
2020-05-20 9:13 ` David Laight
2020-05-11 4:53 ` [PATCH v12 11/18] x86/fsgsbase/64: Use FSGSBASE in switch_to() if available Sasha Levin
2020-05-11 4:53 ` [PATCH v12 12/18] x86/fsgsbase/64: move save_fsgs to header file Sasha Levin
2020-05-11 4:53 ` [PATCH v12 13/18] x86/fsgsbase/64: Use FSGSBASE instructions on thread copy and ptrace Sasha Levin
2020-05-11 4:53 ` [PATCH v12 14/18] x86/speculation/swapgs: Check FSGSBASE in enabling SWAPGS mitigation Sasha Levin
2020-05-11 4:53 ` [PATCH v12 15/18] selftests/x86/fsgsbase: Test ptracer-induced GS base write with FSGSBASE Sasha Levin
2020-05-11 4:53 ` [PATCH v12 16/18] x86/fsgsbase/64: Enable FSGSBASE on 64bit by default and add a chicken bit Sasha Levin
2020-05-11 4:53 ` [PATCH v12 17/18] x86/elf: Enumerate kernel FSGSBASE capability in AT_HWCAP2 Sasha Levin
2020-05-11 4:53 ` [PATCH v12 18/18] Documentation/x86/64: Add documentation for GS/FS addressing mode Sasha Levin
2020-05-15 9:24 ` [PATCH v12 00/18] Enable FSGSBASE instructions Jarkko Sakkinen
2020-05-15 16:40 ` Sasha Levin
2020-05-15 17:55 ` Andi Kleen
2020-05-15 23:07 ` Sasha Levin
2020-05-16 12:21 ` Jarkko Sakkinen
2020-05-16 9:50 ` Jarkko Sakkinen
2020-05-18 15:34 ` Andi Kleen
2020-05-18 20:01 ` Jarkko Sakkinen
2020-05-18 23:03 ` Thomas Gleixner
2020-05-19 16:48 ` Jarkko Sakkinen
2020-05-22 20:14 ` Don Porter
2020-05-22 20:55 ` Dave Hansen
2020-05-23 0:45 ` Thomas Gleixner
2020-05-24 19:45 ` hpa
2020-05-24 21:19 ` Sasha Levin
2020-05-24 23:44 ` hpa
2020-05-25 7:54 ` Richard Weinberger
2020-05-25 21:56 ` Tony Luck
2020-05-26 8:12 ` David Laight
2020-05-26 8:23 ` Richard Weinberger
2020-05-27 8:31 ` Jarkko Sakkinen
2020-05-26 12:42 ` Don Porter
2020-05-26 20:27 ` Sasha Levin
2020-05-26 22:03 ` Don Porter
2020-05-26 22:51 ` Sasha Levin
2020-05-28 17:37 ` Don Porter
2020-05-28 10:29 ` Thomas Gleixner
2020-05-28 17:40 ` Don Porter
2020-05-28 18:38 ` Andy Lutomirski
2020-05-29 15:27 ` Wojtek Porczyk
2020-06-25 15:27 ` Don Porter
2020-06-25 21:37 ` Jarkko Sakkinen
2020-07-18 18:19 ` Don Porter
2020-07-23 3:23 ` Jarkko Sakkinen
2020-05-28 19:19 ` Jarkko Sakkinen
2020-05-28 19:41 ` Sasha Levin
2020-05-29 3:07 ` Jarkko Sakkinen [this message]
2020-05-29 3:10 ` Jarkko Sakkinen
2020-06-25 15:30 ` Don Porter
2020-06-25 21:40 ` Jarkko Sakkinen
2020-05-23 4:19 ` Andi Kleen
2020-05-28 10:36 ` Thomas Gleixner
2020-05-27 8:20 ` Jarkko Sakkinen
2020-05-27 12:42 ` Wojtek Porczyk
2020-05-18 9:51 ` Thomas Gleixner
2020-05-18 15:16 ` Sasha Levin
2020-05-18 18:28 ` Thomas Gleixner
2020-05-18 19:36 ` Jarkko Sakkinen
2020-05-18 6:18 ` Christoph Hellwig
2020-05-18 12:33 ` Sasha Levin
2020-05-18 14:53 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200529030715.GA6182@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=ak@linux.intel.com \
--cc=bp@alien8.de \
--cc=chang.seok.bae@intel.com \
--cc=dave.hansen@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=porter@cs.unc.edu \
--cc=ravi.v.shankar@intel.com \
--cc=sashal@kernel.org \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).