On Sat, Nov 21, 2020 at 10:36:58AM -0800, Andy Lutomirski wrote:
Good morning to everyone.
> Dr. Greg, I know you like sending these emails, but they're not
> really helpful for Linux kernel development. Please see below.
I don't necessarily enjoy sending these e-mails and they take tim
On Sat, Nov 21, 2020 at 08:25:23AM -0800, Dave Hansen wrote:
Good morning, I hope the week has started well for everyone.
> On 11/21/20 7:12 AM, Dr. Greg wrote:
> >> Important Kernel Touch Points
> >> =
> >>
> >> This implement
location, given the
vagaries of e-mail based patch transmission:
ftp://ftp.enjellic.com/pub/sgx/kernel/SFLC-v41.patch
Have a good remainder of the weekend.
Dr. Greg
---
Implement signature based policy controls.
This p
On Wed, Nov 18, 2020 at 07:39:50PM -0600, Haitao Huang wrote:
Good morning, I hope the week is ending well for everyone.
> On Mon, 16 Nov 2020 12:00:23 -0600, Dr. Greg wrote:
>
> >On Thu, Nov 12, 2020 at 02:41:00PM -0800, Andy Lutomirski wrote:
> >>It certainly prevent
On Thu, Nov 12, 2020 at 02:41:00PM -0800, Andy Lutomirski wrote:
Good morning, I hope the week is starting well for everyone.
> On Thu, Nov 12, 2020 at 1:31 PM Dave Hansen wrote:
> >
> > On 11/12/20 12:58 PM, Dr. Greg wrote:
> > > @@ -270,11 +270,10 @@ static int
On Thu, Nov 12, 2020 at 01:31:19PM -0800, Dave Hansen wrote:
Good afternoon to everyone.
> On 11/12/20 12:58 PM, Dr. Greg wrote:
> > @@ -270,11 +270,10 @@ static int sgx_vma_mprotect(struct vm_area_struct
> > *vma,
> > struct vm_area_struct **pprev
ardware
itself will enforce the page permission intents that were encoded when
the enclave was loaded, thus making the subsequent scan irrelevant.
The following patch implements this functionality.
Dr. Greg
---
Subject: [PATCH] Unc
On Sat, Nov 07, 2020 at 11:16:25AM -0800, Dave Hansen wrote:
Good afternoon, I hope the week is going well for everyone.
> On 11/7/20 7:09 AM, Dr. Greg wrote:
> > In all of these discussions there hasn't been a refutation of my point
> > that the only reason this hook is ne
On Fri, Nov 06, 2020 at 09:13:11PM +, Matthew Wilcox wrote:
> On Fri, Nov 06, 2020 at 11:43:59AM -0600, Dr. Greg wrote:
> > The 900 pound primate in the room, that no one is acknowledging, is
> > that this technology was designed to not allow the operating system to
> >
On Fri, Nov 06, 2020 at 09:54:19AM -0800, Dave Hansen wrote:
Good morning, I hope the weekend is going well for everyone, beautiful
weather out here in West-Cental Minnesota.
> On 11/6/20 9:43 AM, Dr. Greg wrote:
> > In light of this, given the decision by the driver authors to not
to do with the per page permissions checks,
even on an EDMM capable driver.
I could go into detail on that issue as well but I hesitate to be an
insufferable bore.
I hope all of this is helpful.
Have a good weekend.
Dr. Greg
As always,
Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defens
estation the PCE and the Provisioning Enclave (PVE) have
access to PROVISION_KEY derivation.
I guess it is up to community consensus as to whether or not this is a
privacy/security sensitive issue. It provides precise enough
identification that Intel uses it to determine whether or not a
plat
On Sat, Oct 24, 2020 at 08:33:21AM -0700, Andy Lutomirski wrote:
Good morning, I hope the week is starting well for everyone.
> > On Oct 24, 2020, at 7:38 AM, Dr. Greg wrote:
> > I can't bring myself to believe that LSM's are going to be written
> > that will be makin
ation
of the namespaced IMA implementation which we believe speaks to the
flexibility of the approach.
> Best regards,
> Krzysztof Struczynski
Hopefully the above reflections are helpful in steering progress of
discussions, if not the price was certainly right.
Best wishes for a productive week to ev
On Tue, Oct 20, 2020 at 09:40:00AM -0700, Sean Christopherson wrote:
Good morning, I hope the week has gone well for everyone.
> On Tue, Oct 20, 2020 at 05:01:18AM -0500, Dr. Greg wrote:
> >
> > With respect to the security issue at hand, the only relevant issue
> > would
On Mon, Oct 19, 2020 at 02:31:05PM -0700, Sean Christopherson wrote:
Good morning, I hope the day is starting well for everyone.
> On Sun, Oct 18, 2020 at 03:49:20AM -0500, Dr. Greg wrote:
> > Is this even a relevant control if we cede the notion of dynamically
> > loadable encl
this may be of assistance.
One of the desires of the SGX user community is to not allow
visibility into enclave code, this is one of the notions/objectives of
confidential computing. The Protected Code Loader that was added by
Intel to their PSW is an acknowledgement of this fact. EDMM and
dynamical
On Mon, Sep 07, 2020 at 12:50:07PM +0100, Luke Hinds wrote:
Good morning, I hope the week is going well for everyone.
> On Sun, Sep 6, 2020 at 6:15 PM Dr. Greg wrote:
> > Just to be clear, we are not campaigning or advocating what we have
> > done but are simply provi
We haven't
campaigned this approach given how complex the kernel development has
become, particurlarly with respect to security infrastructure.
Candidly, given the politics of security technology being viewed as
'constraining' user rights, I think that a lot of forthcoming security
technology ma
e with existing kernel infrastructure. What is needed is
something far simpler that delegates, on the basis of a namespace,
security policy to something other then the kernel, consistent with
what we have learned about policy over the last 29+ years of Linux
development.
With respect to roots of
ivejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hopefully the above is helpful and informative to those who are
interested in these types of issues.
Best wishes for a productive remainder of the week.
Dr. Greg
As always,
Dr. G.W. Wetts
gestions on these
issues have been deemed to be unpopular, if not without merit. They
do, however, come from the perspective of someone who directed a
complete and independent implementation of all of this infrastructure.
A process which has left me with no uncertainty whatsoever with
respect to t
On Fri, May 08, 2020 at 12:56:35PM -0700, Sean Christopherson wrote:
Good morning, I hope the week is proceeding well for everyone.
> On Fri, May 08, 2020 at 02:02:26PM -0500, Dr. Greg wrote:
> > On Thu, May 07, 2020 at 02:41:30AM +0200, Thomas Gleixner wrote:
> > > The diff
own?
Are you using the standard ECALL interface or did the tests run with
the new VDSO entry and exception handler?
Have a good day.
Dr. Greg
As always,
Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defensive
Enjellic Systems Development, LLC IOT platforms and edge devices.
4206 N.
On Thu, May 07, 2020 at 02:41:30AM +0200, Thomas Gleixner wrote:
> Greg,
Good morning Thomas, I hope the week has gone well for you, the same
to everyone else reading this.
> "Dr. Greg" writes:
> > As an aside, for those who haven't spent the last 5+ years of
handling
mechanisms.
Have a good remainder of the day.
Dr. Greg
As always,
Dr. Greg Wettstein, Ph.D, Worker Artisans in autonomously
Enjellic Systems Development, LLC self-defensive IOT platforms
4206 N. 19th Ave. and edge devices.
Fargo, ND 58102
PH: 701-281-1
On Sat, May 02, 2020 at 05:48:30PM -0700, Andy Lutomirski wrote:
Good morning, I hope the week is starting well for everyone.
> > On May 2, 2020, at 4:05 PM, Dr. Greg wrote:
> > In a nutshell, the driver needs our patch that implements
> > cryptographic policy management
Sun, Apr 26, 2020 at 11:57:53AM -0500, Dr. Greg wrote:
> > > > On Wed, Apr 22, 2020 at 12:52:56AM +0300, Jarkko Sakkinen wrote:
> > >
> > > > > The current implementation requires that the firmware sets
> > > > > IA32_SGXLEPUBKEYHASH* MSRs as writ
h
permissions for dynamically executable content, the platform is
completely dependent on the security intentions of the author of the
enclave. Given that, the notion of enduring significant LSM
complexity does not seem to be justified.
Which opens up another set of security implications t
ith respect to SGX dynamic code loading, the future for security
concious architectures, will be to pull the code from remotely
attested repository servers over the network. The only relevant
security question that can be answered is whether or not a platform
owner feels comfortable with that model.
On Wed, Jun 12, 2019 at 07:25:57AM -0700, Sean Christopherson wrote:
Good morning, we hope the week continues to go well for everyone.
> On Wed, Jun 12, 2019 at 04:32:21AM -0500, Dr. Greg wrote:
> > With SGX2 we will, by necessity, have to admit the notion that a
> > platform owne
respect to all of this. I believe if we can focus on a
solution that implements what I have discussed above we will achieve
as much as can be achieved with respect to platform security for SGX
systems.
Best wishes for a productive remainder of the week.
Dr. Greg
As always,
ent
> even if there is no end consumer, e.g. the driver refuses to load due
> to lack of FLC support.
It isn't relevant to these conversations but there will be a version
of this driver supported that runs on non-FLC platforms and that will
support full hardware root of trust via launch en
code that an SGX TEE may ultimately load and
execute.
Any security relevant LSM control in this space has to focus on
providing the platform owner the ability to take action based on the
contents of the SIGSTRUCT of the initiating image. In addition to the
identity of who is requesting the im
t more major and invasive modifications would achieve, given
Cedric's proposal to inherit page permissions from the source, which
is what our runtime already does.
As always, apologies for excessive verbosity beyond LKML sensibilities.
Best wishes for a pleasant remainder of the spring weekend t
terest.
The issue of EDMM has already come up, suffice it to say that EDMM
makes LSM inspection of enclave content, while desirable, largely
irrelevant from a security perspective.
> James Morris
Best wishes for a productive week.
Dr. Greg
As always,
Dr. G.W. Wettstein, Ph.D. Enjellic Sys
gt; the opposite. I completely agree that enclaves should be subject to
> LSM restrictions.
As do we.
The point we have been making is that depending on the LSM's are
depending on the fact that the platform has not been compromised. SGX
is designed to provide a trusted execution
On Mon, Apr 22, 2019 at 08:01:19AM -0700, Sean Christopherson wrote:
Good morning to everyone, I hope the week is starting well.
> On Sat, Apr 20, 2019 at 11:02:47AM -0500, Dr. Greg wrote:
> > We understand and support the need for the LSM to trap these
> > events, but what does
ject
events get forwarded up into a modeling engine running inside of a
namespace specific SGX enclave instance that issues a system call to
instruct an LSM that we wrote, and that pairs with the IMA extension,
to 'discipline' the process if it is acting outside its behavioral
specification.
We wi
On Thu, Apr 18, 2019 at 10:24:42AM -0700, Dave Hansen wrote:
Good morning again.
> On 4/18/19 10:10 AM, Dr. Greg wrote:
> > In addition, the driver breaks all existing SGX software by breaking
> > compatibility with what is a 3+ year ABI provided by the existing
> >
On Thu, Apr 18, 2019 at 11:01:00AM -0700, Dave Hansen wrote:
Good morning to everyone.
> On 4/18/19 10:10 AM, Dr. Greg wrote:
> > Both the current controls for enclave access to the PROVISION
> > attribute and the security controls that are being proposed to emerge
> > for
l hardware.
We have a solution for that as well, but the above is probably enough
cannon fodder for debate so we will leave that sleeping dog lie for
the time being.
Hopefully all of the above is helpful for enhancing the quality of the
Linux SGX eco-system.
Best wishes for a productive weekend.
Dr. Greg
As a
master
branches with respect to all of this?
We have our SFLC patch series currently staged on top of
jarkko-sgx/next and we will re-stage them on top of whatever you are
pushing upstream from.
> /Jarkko
Have a good remainder of the weekend.
Dr. Greg
As always,
Dr. G.W. Wettstein, Ph.D.
On Thu, Dec 20, 2018 at 12:34:00PM +0200, Jarkko Sakkinen wrote:
Good afternoon to everyone.
> On Wed, Dec 19, 2018 at 08:43:43AM -0600, Dr. Greg wrote:
> > I believe it is a silent response to the issues we were
> > prosecuting 4-5 weeks ago, regarding the requirement for an
g on the sidelines
waiting for an indication all of that has some hope of working before
we introduce our approach.
Part of SFLC won't be popular but it is driven by clients who are
actually paying for SGX security engineering and architectures.
> Jethro Beekman | Fortanix
Best wishes f
5 d4 49 8b 84 24 a0 03 00
00 <4c> 8b 30 41 0f b6 c5 89 45 d0 4d 85 f6 74 5e 49 8b 46 10 48 8b 40
Dec 17 10:03:00 nuc2 kernel: RSP: 0018:a51d4238bc98 EFLAGS: 00010246
Dec 17 10:03:00 nuc2 kernel: RAX: dead0100 RBX: RCX:
0000
Dec 17 10:03:00 nuc2 kernel: RDX: 0001b640 RSI: 7f51607ee000 RDI:
a
On Fri, Dec 14, 2018 at 04:06:27PM -0800, Sean Christopherson wrote:
Good afternoon, I hope the weekend is going well for everyone.
> On Fri, Dec 14, 2018 at 05:59:17PM -0600, Dr. Greg wrote:
> > On Wed, Dec 12, 2018 at 08:00:36PM +0200, Jarkko Sakkinen wrote:
> >
> >
On Wed, Dec 12, 2018 at 08:00:36PM +0200, Jarkko Sakkinen wrote:
Good evening, I hope the week has gone well for everyone.
> On Mon, Dec 10, 2018 at 04:49:08AM -0600, Dr. Greg wrote:
> > In the meantime, I wanted to confirm that your jarkko-sgx/master
> > branch contains the
nux SGX support to be relevant, it must admit
mutually distrusting 'SGX runtimes' in the same process context. The
SGX exception handler architecture must also support the notion of
'nested enclave' invocation where an enclave may execute an OCALL and
then go on to execute an enclave, possi
nking about
the ramifications of OCALL's.
So whatever we do has to be simple, straight forward and flexible. If
not the bike shedding will last until something other then SGX gets
invented... :-)
I hope the above reflections are useful.
Best wishes for a productive day.
Dr. Greg
As always,
Just as an aside, secondary to our perception that this technology and
what it can do is not widely understood, we are developing a 2-part
LWN article series on SGX and its implications for Linux.
> Pavel
Best wishes for a good da
On Wed, Nov 28, 2018 at 11:22:28AM -0800, Jarkko Sakkinen wrote:
Good morning, I hope everyone had a pleasant weekend.
> On Wed, Nov 28, 2018 at 04:49:41AM -0600, Dr. Greg wrote:
> > We've been carrying a patch, that drops in on top of the proposed
> > kernel driver, that implem
X I couldn't even conceive of Glibc offering
support and, if it was acceptable to provide support, the potential
timeframe that would be involved in seeing deployment in the field.
As a result, do you anticipate the need for a 'flag day' with respect
to URTS/PSW/SDK support for all of this?
In additi
X I couldn't even conceive of Glibc offering
support and, if it was acceptable to provide support, the potential
timeframe that would be involved in seeing deployment in the field.
As a result, do you anticipate the need for a 'flag day' with respect
to URTS/PSW/SDK support for all of this?
In additi
On Tue, Nov 27, 2018 at 09:55:45AM -0800, Andy Lutomirski wrote:
> > On Nov 27, 2018, at 8:41 AM, Jarkko Sakkinen
> > wrote:
> >
> >> On Tue, Nov 27, 2018 at 02:55:33AM -0600, Dr. Greg wrote:
> >> Since the thread has become a bit divergent I wanted to note
On Tue, Nov 27, 2018 at 09:55:45AM -0800, Andy Lutomirski wrote:
> > On Nov 27, 2018, at 8:41 AM, Jarkko Sakkinen
> > wrote:
> >
> >> On Tue, Nov 27, 2018 at 02:55:33AM -0600, Dr. Greg wrote:
> >> Since the thread has become a bit divergent I wanted to note
hinking about these issues and the above framework provides the
most flexible architecture available.
> /Jarkko
We would be happy to discuss specific aspects of the implementation.
Have a good day.
Dr. Greg
As always,
Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC.
4206 N. 19th Ave.
hinking about these issues and the above framework provides the
most flexible architecture available.
> /Jarkko
We would be happy to discuss specific aspects of the implementation.
Have a good day.
Dr. Greg
As always,
Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC.
4206 N. 19th Ave.
On Nov 25, 2018, at 1:59 PM, Andy Lutomirski wrote:
> >> On Nov 25, 2018, at 10:55 AM, Dr. Greg wrote:
> >>
> >> The notion of a launch enclave is critical to establishing these
> >> guarantees. As soon as the kernel becomes involved in implementing
> >
On Nov 25, 2018, at 1:59 PM, Andy Lutomirski wrote:
> >> On Nov 25, 2018, at 10:55 AM, Dr. Greg wrote:
> >>
> >> The notion of a launch enclave is critical to establishing these
> >> guarantees. As soon as the kernel becomes involved in implementing
> >
used or setup. It also establishes a cryptographic rather then a
filesystem based guarantee on the launch enclave being used.
If the lists are empty the kernel simply proceeds as it does now and
loads any enclave submitted to it.
I believe this architecture has a number of merits. It largely
used or setup. It also establishes a cryptographic rather then a
filesystem based guarantee on the launch enclave being used.
If the lists are empty the kernel simply proceeds as it does now and
loads any enclave submitted to it.
I believe this architecture has a number of merits. It largely
le to them,
within the constraints of upstream sensibility, without whacking on
the kernel.
As it stands now the driver has both privacy and potential system
security issues which translate into useability and desirability
implications for SGX on Linux moving forward.
> /Jarkko
Have a good remainde
le to them,
within the constraints of upstream sensibility, without whacking on
the kernel.
As it stands now the driver has both privacy and potential system
security issues which translate into useability and desirability
implications for SGX on Linux moving forward.
> /Jarkko
Have a good remainde
On Sat, Nov 24, 2018 at 08:15:21AM -0800, Jarkko Sakkinen wrote:
> On Tue, Nov 20, 2018 at 05:15:08AM -0600, Dr. Greg wrote:
> > Malware would not necessarily need the Intel attestation service.
> > Once access to the PROVISION bit is available, malware teams could
> > s
On Sat, Nov 24, 2018 at 08:15:21AM -0800, Jarkko Sakkinen wrote:
> On Tue, Nov 20, 2018 at 05:15:08AM -0600, Dr. Greg wrote:
> > Malware would not necessarily need the Intel attestation service.
> > Once access to the PROVISION bit is available, malware teams could
> > s
On Thu, Nov 22, 2018 at 12:56:23PM -0800, Andy Lutomirski wrote:
Good morning to everyone.
> On Thu, Nov 22, 2018 at 3:12 AM Dr. Greg wrote:
> > In addition, we are not confident
> > the driver will be useful to anything other then server class hardware
> > and will be in
On Thu, Nov 22, 2018 at 12:56:23PM -0800, Andy Lutomirski wrote:
Good morning to everyone.
> On Thu, Nov 22, 2018 at 3:12 AM Dr. Greg wrote:
> > In addition, we are not confident
> > the driver will be useful to anything other then server class hardware
> > and will be in
r requires the consideration of a lot of issues which, in our
opinion, have not been fully represented in the discussions to date.
> /Jarkko
I hope the above is useful for framing future discussions.
Have a good remainder of the week.
Dr. Greg
As always,
Dr. G.W. Wettstein, Ph.D. Enj
r requires the consideration of a lot of issues which, in our
opinion, have not been fully represented in the discussions to date.
> /Jarkko
I hope the above is useful for framing future discussions.
Have a good remainder of the week.
Dr. Greg
As always,
Dr. G.W. Wettstein, Ph.D. Enj
n is useful to the development dialogue.
Developing a community driver is tedious at best, particularly for
hardware such as this. Our personal thanks to Jarkko and others who
have been working through these issues.
Best wishes for a productive remainder of the week and for a pleasant
n is useful to the development dialogue.
Developing a community driver is tedious at best, particularly for
hardware such as this. Our personal thanks to Jarkko and others who
have been working through these issues.
Best wishes for a productive remainder of the week and for a pleasant
ded sounds a bit
clunky at best.
At worst it has potential security implications since it is the
reponsibility of the enclave launch control infrastructure to control
which enclaves are allowed to have the PROVISION_KEY attribute bit
set.
Have a good weekend.
Dr. Greg
As always,
Dr. G.W. Wettstein,
ded sounds a bit
clunky at best.
At worst it has potential security implications since it is the
reponsibility of the enclave launch control infrastructure to control
which enclaves are allowed to have the PROVISION_KEY attribute bit
set.
Have a good weekend.
Dr. Greg
As always,
Dr. G.W. Wettstein,
nality.
That would significantly increase the ability for this driver to be
supported and tested.
Once again, thanks for all the legwork on the driver, however you are
managing to exercise its functionality.
Dr. Greg
As always,
Dr. Greg Wettstein, Ph.D. Enjellic Systems Development, LLC
nality.
That would significantly increase the ability for this driver to be
supported and tested.
Once again, thanks for all the legwork on the driver, however you are
managing to exercise its functionality.
Dr. Greg
As always,
Dr. Greg Wettstein, Ph.D. Enjellic Systems Development, LLC
On Mon, Apr 02, 2018 at 07:20:54AM -0400, Stefan Berger wrote:
Good morning to everyone.
> On 03/29/2018 01:44 PM, Dr. Greg Wettstein wrote:
> >On Mar 28, 8:44am, Stefan Berger wrote:
> >} Subject: Re: [RFC PATCH v3 1/3] ima: extend clone() with IMA namespace
> >sup
> &
On Mon, Apr 02, 2018 at 07:20:54AM -0400, Stefan Berger wrote:
Good morning to everyone.
> On 03/29/2018 01:44 PM, Dr. Greg Wettstein wrote:
> >On Mar 28, 8:44am, Stefan Berger wrote:
> >} Subject: Re: [RFC PATCH v3 1/3] ima: extend clone() with IMA namespace
> >sup
> &
On Mar 28, 8:44am, Stefan Berger wrote:
} Subject: Re: [RFC PATCH v3 1/3] ima: extend clone() with IMA namespace sup
Good morning, I hope the week is going well for everyone.
> On 03/28/2018 08:14 AM, Dr. Greg Wettstein wrote:
> > On Wed, Mar 28, 2018 at 07:10:12AM -0400, Stefan Ber
On Mar 28, 8:44am, Stefan Berger wrote:
} Subject: Re: [RFC PATCH v3 1/3] ima: extend clone() with IMA namespace sup
Good morning, I hope the week is going well for everyone.
> On 03/28/2018 08:14 AM, Dr. Greg Wettstein wrote:
> > On Wed, Mar 28, 2018 at 07:10:12AM -0400, Stefan Ber
icularly of the symmetric
variety, but userspace seems to be a much better place for a lot of
this functionality. If the ELF module discussion is any indication it
appears as if userspace and the kernel may be destined to become more
symbiotic in the future.
Just our two cents.
&g
much better place for a lot of
this functionality. If the ELF module discussion is any indication it
appears as if userspace and the kernel may be destined to become more
symbiotic in the future.
Just our two cents.
>Stefan
Have a good remainder of the week.
Dr. Greg
As always,
aracteristic.
We have already written the futuristic LSM that Alan aludes to in
order to implement per COE security policies and forensics for
actors/COE's that have gone over to the 'dark side'.
> Alan
Have a good weekend.
Dr. Greg
}-- End of excerpt from Alan Cox
As always,
Dr. G.W. Wetts
lready written the futuristic LSM that Alan aludes to in
order to implement per COE security policies and forensics for
actors/COE's that have gone over to the 'dark side'.
> Alan
Have a good weekend.
Dr. Greg
}-- End of excerpt from Alan Cox
As always,
Dr. G.W. Wettstein, Ph.D. Enjellic Sys
as well, since the issues are all related.
> On Thu, Jan 04, 2018 at 03:06:43AM -0600, Dr. Greg Wettstein wrote:
> > If we are talking about the issues motivating the KPTI work I don't
> > have any useful information beyond what is raging through the industry
> > right now.
as well, since the issues are all related.
> On Thu, Jan 04, 2018 at 03:06:43AM -0600, Dr. Greg Wettstein wrote:
> > If we are talking about the issues motivating the KPTI work I don't
> > have any useful information beyond what is raging through the industry
> > right now.
On Jan 4, 3:27pm, Greg Kroah-Hartman wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver
Wild day, enjoyed by all I'm sure.
> On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote:
> > So how does this protect against the MELTDOWN attack (CVE-2017-5754)
> > and the MELTATOMBOMBA4
On Jan 4, 3:27pm, Greg Kroah-Hartman wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver
Wild day, enjoyed by all I'm sure.
> On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote:
> > So how does this protect against the MELTDOWN attack (CVE-2017-5754)
> > and the MELTATOMBOMBA4
On Jan 3, 10:48am, Pavel Machek wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver
> Hi!
Good morning.
> :-). Stuff proceeds as usual. Too bad it is raining outside, instead
> of snowing.
-19C here, so we have snow... :-)
> > > So ... even with SGX, host can generate bitflips in the
On Jan 3, 10:48am, Pavel Machek wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver
> Hi!
Good morning.
> :-). Stuff proceeds as usual. Too bad it is raining outside, instead
> of snowing.
-19C here, so we have snow... :-)
> > > So ... even with SGX, host can generate bitflips in the
ding, given what
appears to be the difficulty of some Intel processors to deal with
page faults induced by speculative memory references... :-)
Best wishes for a productive New Year.
Dr. Greg
}-- End of excerpt from Pavel Machek
As always,
Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC.
4206 N.
ding, given what
appears to be the difficulty of some Intel processors to deal with
page faults induced by speculative memory references... :-)
Best wishes for a productive New Year.
Dr. Greg
}-- End of excerpt from Pavel Machek
As always,
Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC.
4206 N.
tboot which underscores a future involving the integration of
these technologies.
Unfortunately, in the security field it is way more fun, and seemingly
advantageous from a reputational perspective, to break things then to
build solutions :-)(
> Pavel
I hope the above clarifications are helpful.
Best
tboot which underscores a future involving the integration of
these technologies.
Unfortunately, in the security field it is way more fun, and seemingly
advantageous from a reputational perspective, to break things then to
build solutions :-)(
> Pavel
I hope the above clarifications are helpful.
Best
On Mon, May 29, 2017 at 01:32:38PM -0400, Mimi Zohar wrote:
> Hi Guilherme,
>
> (Wow, you should did Cc a lot of people.)
Indeed.
We have namespaced a significant amount of the IMA code so we will
continue the broadcast, under the assumption that this is of general
interest to the community.
On Mon, May 29, 2017 at 01:32:38PM -0400, Mimi Zohar wrote:
> Hi Guilherme,
>
> (Wow, you should did Cc a lot of people.)
Indeed.
We have namespaced a significant amount of the IMA code so we will
continue the broadcast, under the assumption that this is of general
interest to the community.
stein, Ph.D. Enjellic Systems Development, LLC.
4206 N. 19th Ave. Specializing in information infra-structure
Fargo, ND 58102development.
PH: 701-281-1686
FAX: 701-281-3949 EMAIL: g...@enjellic.com
--
"You've got to be kidding me Nate. You've seen the shit that has come
through my office in the last two hours. You think I'm even remotely
worried about one SATA cable being six inches longer than the other."
-- Dr. Greg Wettstein
Resurrection
formation infra-structure
Fargo, ND 58102development.
PH: 701-281-1686
FAX: 701-281-3949 EMAIL: g...@enjellic.com
--
"You've got to be kidding me Nate. You've seen the shit that has come
through my office in the last two hours. You think I'm even remotely
worried about one SATA cable being six inches longer than the other."
-- Dr. Greg Wettstein
Resurrection
On Fri, Feb 17, 2017 at 02:37:12PM +0200, Jarkko Sakkinen wrote:
Hi, I hope the week is ending well for everyone.
> On Fri, Feb 17, 2017 at 03:56:26AM -0600, Dr. Greg Wettstein wrote:
> > On Thu, Feb 16, 2017 at 10:33:04PM +0200, Jarkko Sakkinen wrote:
> >
> > Goo
On Fri, Feb 17, 2017 at 02:37:12PM +0200, Jarkko Sakkinen wrote:
Hi, I hope the week is ending well for everyone.
> On Fri, Feb 17, 2017 at 03:56:26AM -0600, Dr. Greg Wettstein wrote:
> > On Thu, Feb 16, 2017 at 10:33:04PM +0200, Jarkko Sakkinen wrote:
> >
> > Goo
1 - 100 of 134 matches
Mail list logo