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 5.8-r
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 so
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 poi
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 trivi
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 hour
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
> 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 rese
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 e
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.
So
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 retir
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 featur
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 a
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 lo
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 unpriviledge
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
Registra
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 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 specificall
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 create
> 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 took
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? W
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 TCS's)
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 reg
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 d
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 enclav
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 out-of-tr
> 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 (such
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 wh
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 ad
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 in
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.
>
> Inde
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 segment
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 a
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 o
> 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.
-And
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 m
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
> base
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 addresses. The operating system controls whether applications
52 matches
Mail list logo
