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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200625213705.GF20341@linux.intel.com>
Date:   Fri, 26 Jun 2020 00:37:05 +0300
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Don Porter <porter@...unc.edu>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        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 Thu, Jun 25, 2020 at 11:27:28AM -0400, Don Porter wrote:
> On 5/29/20 11:27 AM, Wojtek Porczyk wrote:
> > On Thu, May 28, 2020 at 11:38:01AM -0700, Andy Lutomirski wrote:
> > > 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.
> > 
> > We currently run as part of CI several workloads[1], among them LTP tests[2],
> > and sometimes it's not pretty, because we encounter stability problems in
> > Graphene+SGX even without the patchset. We'll pick some stable subset and
> > will let know. Right now we'll have to retool CI for custom kernels, which
> > will take some back and forth with uni's admins.
> > 
> > [1] https://github.com/oscarlab/graphene/tree/master/Examples
> > [2] https://github.com/oscarlab/graphene/tree/master/LibOS/shim/test/ltp
> > 
> 
> Following up: we have been running a patched 5.7 kernel with v12 of this
> series on one of our CI workers.  As Wojtek mentions, infrastructure and
> other orthogonal issues took some time.
> 
> We have run our complete SGX testing pipelines successfully several times
> with no issues: no errors in Graphene or suspicious kernel messages.
> 
> I also did Andy's suggested test:
> * 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
> 
> Again, no apparent issues, nothing in dmesg.  I ran a similar setup with our
> SGX-specific Graphene (PAL) unit tests.  Same story: everything looks good.
> 
> Let us know if we can be of any more help here.
> 
> Thanks,
> Don

Can unmodified Graphene-SGX used with these changes?

/Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ