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 the
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
also available from the following 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
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 prevents a
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
hardware
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
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 n
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
ade as to what anyone
would actually be able 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 Wettstei
e access to PROVISION_KEY derivation.
In EPID attestation 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 tha
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 wil
of implementation. Both approaches required no modification
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 w
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
thing practical like 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
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 providing
campaigning or advocating what we have
done but are simply providing background for discussion. 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
ven how entangled it has
become 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.
nd advancement faces.
> (english) http://www.livejournal.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
orners on anyone.
I think everyone will concede that my ideas and suggestions 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 proc
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 diffsta
your 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.
42
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 their
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 writabl
icated in the past, once the enclave is initialized with
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.
W
ion and function of the LSM.
With 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 f
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
s easy to get lost in
minutia with 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
sume resources for EPC management
> 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 h
any visibility into the 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
ut the same level of security
effect that 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
lable if there is interest.
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,
, actually
> 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
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
of behavioral namespaces. The actor/subject
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
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
> > d
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
ition of only working sporadically
and will not be a universal solution for all 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 q
-sgx/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
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 SG
API we are sitting 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 | Fo
e8 67 97 f7 ff 89 45 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: 0000 RCX:
0000
Dec 17 10:03:00 nuc2 kernel: RDX: 0001b640 RSI: 7f51607e
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:
> >
> > Goo
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 propo
stering SGX exception handlers under their management.
In order for mainline Linux 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 enclav
h means we need to be thinking 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 product
and cryptographically enforced access controls.
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.
>
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 i
tructure and exit
handler? VDSO's are typically the domain of the system library.
Given the nature of SGX 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 r
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
s anyone. We have spent a lot of
time thinking 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 Syst
ov 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
> >>
ntage of requiring that the
kernel know about all the different ways that a launch enclave might
be 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
is technology have the best tools available 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
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
ucing a useful
driver 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. We
river needs the ability to
function in both launch control modes.
> --Andy
Hopefully the above information 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
h
orrect root signing key is loaded 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
A
ons needed to support the stated functionality.
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, P
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
ariety, 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.
>Stefan
Have a good remainder
is a namespaceable characteristic.
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 A
gine below 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
> >
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 w
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 encla
pending, 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, LL
candidate for this is
TXT/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 abov
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.
C
Dr. G.W. Wettstein, 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
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 Thu, Feb 16, 2017 at 10:33:04PM +0200, Jarkko Sakkinen wrote:
Good morning to everyone.
> On Thu, Feb 16, 2017 at 02:06:42PM -0600, Dr. Greg Wettstein wrote:
> > Just as an aside, has anyone given any thought about TPM2 resource
> > management in things like TXT/tboot env
On Thu, Feb 16, 2017 at 09:04:47AM -0500, Ken Goldman wrote:
Good morning to everyone, leveraging some time between planes.
> On 2/14/2017 9:38 AM, Dr. Greg Wettstein wrote:
> >
> >I don't think there is any doubt that running cryptographic primitives
> >in userspace
On Fri, Feb 10, 2017 at 04:13:05PM -0500, Kenneth Goldman wrote:
Good morning to everyone.
> James Bottomley wrote on
> 02/10/2017 11:46:03 AM:
>
> > > quote: 810 milliseconds
> > > verify signature: 635 milliseconds
For those who may be interested in this sort of thing I grabbed a few
minute
On Feb 9, 11:24am, James Bottomley wrote:
} Subject: Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global sessi
Good morning to everyone.
> On Thu, 2017-02-09 at 03:06 -0600, Dr. Greg Wettstein wrote:
> > Referring back to Ken's comments about having 20+ clients waiting to
On Jan 30, 11:58pm, Jarkko Sakkinen wrote:
} Subject: Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global sessi
Good morning, I hope the day is going well for everyone.
> I'm kind dilating to an opinion that we would leave this commit out
> from the first kernel release that will contain
On Jan 20, 5:22pm, Boris Ostrovsky wrote:
} Subject: Re: [PATCH] tpm: Restore functionality to xen vtpm driver.
> On 01/20/2017 10:00 AM, Dr. Greg Wettstein wrote:
> > Functionality of the xen-tpmfront driver was lost secondary to
> > the introduction of xenbus multi-page
ase in which multi-page xenbus support was introduced.
Daniel De Graaf formulated the fix by code inspection after the
regression point was located.
Cc: # 4.1-
Suggested-by: Daniel De Graaf
Signed-off-by: Dr. Greg Wettstein
---
drivers/char/tpm/xen-tpmfront.c | 2 +-
1 file changed, 1 ins
On Jan 3, 5:21pm, Ken Goldman wrote:
} Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager
Good morning, I hope this note finds the day going well for everyone.
> On 1/3/2017 4:47 PM, Jason Gunthorpe wrote:
> >
> > I think we should also consider TPM 1.2 support in all of
ase in which multi-page xenbus support was introduced.
Daniel De Graaf formulated the fix by code inspection after the
regression point was located.
Signed-off-by: Dr. Greg Wettstein
---
drivers/char/tpm/xen-tpmfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/
On Sun, May 08, 2016 at 06:32:10PM -0700, Andy Lutomirski wrote:
Good morning, running behind on e-mail this week but wanted to get
some reflections out on Andy's well taken comments and concerns.
> On May 8, 2016 2:59 AM, "Dr. Greg Wettstein" wrote:
> >
> >
>
On Mon, May 09, 2016 at 08:27:04AM +0200, Thomas Gleixner wrote:
Good morning.
> > On Fri, 6 May 2016, Jarkko Sakkinen wrote:
> > I fully understand if you (and others) want to keep this standpoint but
> > what if we could get it to staging after I've revised it with suggested
> >
> This should n
Hi, I hope the weekend is going well for everyone.
On Fri, May 06, 2016 at 02:39:44PM +0300, Jarkko Sakkinen wrote:
> On Tue, May 03, 2016 at 04:06:27AM -0500, Dr. Greg Wettstein wrote:
> > It would be helpful and instructive for anyone involved in this debate
> > to review th
On Tue, May 03, 2016 at 05:38:40PM +0200, Pavel Machek wrote:
> Hi!
Good morning, I hope everyone's day is starting out well.
> > I told my associates the first time I reviewed this technology that
> > SGX has the ability to be a bit of a Pandora's box and it seems to be
> > following that cours
On May 2, 11:37am, "Austin S. Hemmelgarn" wrote:
} Subject: Re: [PATCH 0/6] Intel Secure Guard Extensions
Good morning, I hope the day is starting out well for everyone.
> On 2016-04-29 16:17, Jarkko Sakkinen wrote:
> > On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote:
> >> On Mon 201
On Mar 26, 9:32am, Christoph Hellwig wrote:
} Subject: [PATCH 1/3] pmem: Initial version of persistent memory driver
Hi, I hope the week has been going well for everyone.
> From: Ross Zwisler
>
> PMEM is a new driver that presents a reserved range of memory as a
> block device. This is useful
On Jun 15, 8:43pm, Curtis wrote:
} Subject: Re: [Scst-devel] ANNOUNCE: Hugepage (HPD) block device driver.
> Greg,
Hi Curtis, hope your is starting out well.
> this project looks quite interesting, and I hope to try it out soon,
> however I do have one question, though it may expose my ignoran
s. Anyone who has been snooted by a Golden Retriever will tell
you how difficult they are to resist once they put their mind to
something. Anyone who finds this driver useful should note that he
enjoys the large Milk Bone (tm) dog biscuits :-)
Best wishes for a productive week.
Dr Greg and Iz
93 matches
Mail list logo
