On Sat, Jul 18, 2020 at 02:19:52PM -0400, Don Porter wrote:
> On 6/25/20 5:37 PM, Jarkko Sakkinen wrote:
> >
> > Can unmodified Graphene-SGX used with these changes?
> >
>
> Yes. I just double-checked that all of the needed changes have made it to
> master branch.
>
> I also re-tested on
On 6/25/20 5:37 PM, Jarkko Sakkinen wrote:
Can unmodified Graphene-SGX used with these changes?
Yes. I just double-checked that all of the needed changes have made it
to master branch.
I also re-tested on 5.8-rc1 with v13 of the patch, and it looks good.
On Thu, Jun 25, 2020 at 11:30:54AM -0400, Don Porter wrote:
> We are merging the changes to Graphene to run a patched 5.7 kernel with
> these patches, so it should work for you (or anyone else) once all of the
> changes are merged. I'd be happy to talk, perhaps off this thread, about
> how we can
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
On 5/28/20 11:10 PM, Jarkko Sakkinen wrote:
On Fri, May 29, 2020 at 06:07:23AM +0300, Jarkko Sakkinen wrote:
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
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
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
On Fri, May 29, 2020 at 06:07:23AM +0300, Jarkko Sakkinen wrote:
> 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 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
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
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
> On May 28, 2020, at 10:40 AM, 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
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
On 5/26/20 6:51 PM, Sasha Levin wrote:
On Tue, May 26, 2020 at 06:03:35PM -0400, Don Porter wrote:
On 5/26/20 4:27 PM, Sasha Levin wrote:
I'm really worried about the disconnect between how you view the current
state of Graphene (and the industry) vs Intel and the various cloud
providers.
Andi,
Andi Kleen writes:
>> Setting the fs register in userspace is an essential feature for running
>> legacy code in SGX. We have been following LKML discussions on this
>> instruction for years, and hoping this feature would be supported by Linux,
>
> If you need a feature you should comment
Don,
Don Porter writes:
> On 5/22/20 8:45 PM, Thomas Gleixner wrote:
> The threat model for Graphene, and most SGX papers, is quite explicit:
> we assume that Intel’s CPU package, the software in the enclave, and
> possibly Intel’s Attestation Service (IAS) are the only trusted
> components.
On Wed, May 27, 2020 at 11:20:08AM +0300, Jarkko Sakkinen wrote:
> On Fri, 2020-05-22 at 16:14 -0400, Don Porter wrote:
> > legacy code in SGX. We have been following LKML discussions on this
> > instruction for years, and hoping this feature would be supported by
> > Linux, so that we can
On Sun, 2020-05-24 at 12:45 -0700, h...@zytor.com wrote:
> On a related topic (needless to say, this should never have happened
> and is being raised at the highest levels inside Intel):
>
> There are legitimate reasons to write a root-hole module, the main one
> being able to test security
On Fri, 2020-05-22 at 16:14 -0400, Don Porter wrote:
> legacy code in SGX. We have been following LKML discussions on this
> instruction for years, and hoping this feature would be supported by
> Linux, so that we can retire this module. To our knowledge, every SGX
Why have you followed this
On Tue, May 26, 2020 at 06:03:35PM -0400, Don Porter wrote:
On 5/26/20 4:27 PM, Sasha Levin wrote:
I'm really worried about the disconnect between how you view the current
state of Graphene (and the industry) vs Intel and the various cloud
providers.
You keep suggesting that its just past the
On 5/26/20 4:27 PM, Sasha Levin wrote:
On Tue, May 26, 2020 at 08:42:09AM -0400, Don Porter wrote:
On 5/22/20 8:45 PM, Thomas Gleixner wrote:
let me clarify, that despite your intentions:
- there is not a single word in any paper, slide deck, documentation
etc. which mentions that
On Tue, May 26, 2020 at 08:42:09AM -0400, Don Porter wrote:
On 5/22/20 8:45 PM, Thomas Gleixner wrote:
let me clarify, that despite your intentions:
- there is not a single word in any paper, slide deck, documentation
etc. which mentions that loading this module and enabling FSGSBASE
Hi Thomas,
On 5/22/20 8:45 PM, Thomas Gleixner wrote:
Don,
Don Porter writes:
On 5/19/20 12:48 PM, Jarkko Sakkinen wrote:
On Tue, May 19, 2020 at 01:03:25AM +0200, Thomas Gleixner wrote:
That justifies to write books which recommend to load a kernel module
which creates a full
ernel" ,
> "bp" , "Andy Lutomirski" , "Dave Hansen"
> , "Tony Luck"
> , "Ravi V Shankar" , "chang
> seok bae"
> Gesendet: Dienstag, 26. Mai 2020 10:12:02
> Betreff: RE: Re: [PATCH v12 00/18] Enable FSGSBASE instruct
From: Richard Weinberger
> Sent: 25 May 2020 08:55
...
> P: Sadly too. Mostly because customer has custom module and forgot to set it
> GPL
You want us to lie that custom modules are GPL?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
pr_warn("** If you see this message and you are not debugging**\n");
>pr_warn("** the kernel, report this immediately to your vendor!
> **\n");
>pr_warn("**
> **\n");
>pr_warn("** NOTICE NOTICE NOTICE
On Sun, May 24, 2020 at 11:20 PM Sasha Levin wrote:
>
> On Sun, May 24, 2020 at 12:45:18PM -0700, h...@zytor.com wrote:
> >There are legitimate reasons to write a root-hole module, the main one being
> >able to test security features like SMAP. I have requested before a TAINT
> >flag
On May 24, 2020 2:19:45 PM PDT, Sasha Levin wrote:
>On Sun, May 24, 2020 at 12:45:18PM -0700, h...@zytor.com wrote:
>>There are legitimate reasons to write a root-hole module, the main one
>being able to test security features like SMAP. I have requested before
>a TAINT flag specifically for this
On Sun, May 24, 2020 at 12:45:18PM -0700, h...@zytor.com wrote:
There are legitimate reasons to write a root-hole module, the main one being
able to test security features like SMAP. I have requested before a TAINT flag
specifically for this purpose, because TAINT_CRAP is nowhere near explicit
On May 22, 2020 5:45:39 PM PDT, Thomas Gleixner wrote:
>Don,
>
>Don Porter writes:
>> On 5/19/20 12:48 PM, Jarkko Sakkinen wrote:
>>> On Tue, May 19, 2020 at 01:03:25AM +0200, Thomas Gleixner wrote:
That justifies to write books which recommend to load a kernel
>module
which
> Setting the fs register in userspace is an essential feature for running
> legacy code in SGX. We have been following LKML discussions on this
> instruction for years, and hoping this feature would be supported by Linux,
If you need a feature you should comment on it. One of the reasons
it
Don,
Don Porter writes:
> On 5/19/20 12:48 PM, Jarkko Sakkinen wrote:
>> On Tue, May 19, 2020 at 01:03:25AM +0200, Thomas Gleixner wrote:
>>>
>>> That justifies to write books which recommend to load a kernel module
>>> which creates a full unpriviledged root hole. I bet none of these papers
>>>
On 5/22/20 1:14 PM, Don Porter wrote:
> I wanted to clarify that we never intended the Graphene kernel module
> you mention for production use, as well as to comment in support of this
> patch.
Could you also clarify: Did you know that the FSGSBASE kernel module
introduced a root vulnerability?
On 5/19/20 12:48 PM, Jarkko Sakkinen wrote:
On Tue, May 19, 2020 at 01:03:25AM +0200, Thomas Gleixner wrote:
Jarkko Sakkinen writes:
On Mon, 2020-05-18 at 08:34 -0700, Andi Kleen wrote:
Yes, for SGX this is functional feature because enclave entry points,
thread control structures (aka
On Tue, May 19, 2020 at 01:03:25AM +0200, Thomas Gleixner wrote:
> Jarkko Sakkinen writes:
> > On Mon, 2020-05-18 at 08:34 -0700, Andi Kleen wrote:
> >> > Yes, for SGX this is functional feature because enclave entry points,
> >> > thread control structures (aka TCS's), reset FSBASE and GSBASE
Jarkko Sakkinen writes:
> On Mon, 2020-05-18 at 08:34 -0700, Andi Kleen wrote:
>> > Yes, for SGX this is functional feature because enclave entry points,
>> > thread control structures (aka TCS's), reset FSBASE and GSBASE registers
>> > to fixed (albeit user defined) values. And syscall's can be
On Mon, 2020-05-18 at 08:34 -0700, Andi Kleen wrote:
> > Yes, for SGX this is functional feature because enclave entry points,
> > thread control structures (aka TCS's), reset FSBASE and GSBASE registers
> > to fixed (albeit user defined) values. And syscall's can be done only
> > outside of
On Mon, 2020-05-18 at 11:51 +0200, Thomas Gleixner wrote:
> Sasha Levin writes:
> > On Fri, May 15, 2020 at 12:24:14PM +0300, Jarkko Sakkinen wrote:
> > > Can you put me to the CC-loop for this patches. Some SGX-enabled
> > > frameworks such as Graphene use out-of-tree changes to achieve this.
>
Sasha Levin writes:
> On Mon, May 18, 2020 at 11:51:07AM +0200, Thomas Gleixner wrote:
>>Sasha Levin writes:
>>> On Fri, May 15, 2020 at 12:24:14PM +0300, Jarkko Sakkinen wrote:
Can you put me to the CC-loop for this patches. Some SGX-enabled
frameworks such as Graphene use
> Yes, for SGX this is functional feature because enclave entry points,
> thread control structures (aka TCS's), reset FSBASE and GSBASE registers
> to fixed (albeit user defined) values. And syscall's can be done only
> outside of enclave.
>
> This is a required feature for fancier runtimes
On Mon, May 18, 2020 at 11:51:07AM +0200, Thomas Gleixner wrote:
Sasha Levin writes:
On Fri, May 15, 2020 at 12:24:14PM +0300, Jarkko Sakkinen wrote:
Can you put me to the CC-loop for this patches. Some SGX-enabled
frameworks such as Graphene use out-of-tree changes to achieve this.
That's
Cc: +x...@kernel.org
Sasha Levin writes:
> Benefits:
> Currently a user process that wishes to read or write the FS/GS base must
> make a system call. But recent X86 processors have added new instructions
> for use in 64-bit mode that allow direct access to the FS and GS segment
> base
On Sun, May 17, 2020 at 11:18:36PM -0700, Christoph Hellwig wrote:
On Mon, May 11, 2020 at 12:52:53AM -0400, Sasha Levin wrote:
Benefits:
Currently a user process that wishes to read or write the FS/GS base must
make a system call. But recent X86 processors have added new instructions
for use
Sasha Levin writes:
> On Fri, May 15, 2020 at 12:24:14PM +0300, Jarkko Sakkinen wrote:
>>
>>Can you put me to the CC-loop for this patches. Some SGX-enabled
>>frameworks such as Graphene use out-of-tree changes to achieve this.
>>That's where the interest to possibly test this comes from.
>
>
On Mon, May 11, 2020 at 12:52:53AM -0400, Sasha Levin wrote:
> Benefits:
> Currently a user process that wishes to read or write the FS/GS base must
> make a system call. But recent X86 processors have added new instructions
> for use in 64-bit mode that allow direct access to the FS and GS
On Fri, 2020-05-15 at 10:55 -0700, Andi Kleen wrote:
> > Indeed, we've seen a few hacks that basically just enable FSGSBASE:
> >
> > - https://github.com/oscarlab/graphene-sgx-driver
> > - https://github.com/occlum/enable_rdfsbase
> >
> > And would very much like to get rid of them...
>
> These
On Fri, 2020-05-15 at 12:40 -0400, Sasha Levin wrote:
> > Can you put me to the CC-loop for this patches. Some SGX-enabled
>
> Sure!
>
> > frameworks such as Graphene use out-of-tree changes to achieve this.
> > That's where the interest to possibly test this comes from.
>
> Indeed, we've seen
On Fri, May 15, 2020 at 10:55:50AM -0700, Andi Kleen wrote:
Indeed, we've seen a few hacks that basically just enable FSGSBASE:
- https://github.com/oscarlab/graphene-sgx-driver
- https://github.com/occlum/enable_rdfsbase
And would very much like to get rid of them...
These are insecure and
> Indeed, we've seen a few hacks that basically just enable FSGSBASE:
>
> - https://github.com/oscarlab/graphene-sgx-driver
> - https://github.com/occlum/enable_rdfsbase
>
> And would very much like to get rid of them...
These are insecure and open root holes without the patches
used here.
On Fri, May 15, 2020 at 12:24:14PM +0300, Jarkko Sakkinen wrote:
On Mon, 2020-05-11 at 00:52 -0400, Sasha Levin wrote:
Benefits:
Currently a user process that wishes to read or write the FS/GS base must
make a system call. But recent X86 processors have added new instructions
for use in 64-bit
On Mon, 2020-05-11 at 00:52 -0400, Sasha Levin wrote:
> Benefits:
> Currently a user process that wishes to read or write the FS/GS base must
> make a system call. But recent X86 processors have added new instructions
> for use in 64-bit mode that allow direct access to the FS and GS segment
>
51 matches
Mail list logo
