Re: [PATCH v13 10/13] x86/sgx: Add sgx_einit() for initializing enclaves

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,

Re: [PATCH v13 02/13] x86/cpufeature: Add SGX and SGX_LC CPU features

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [RFC PATCH v2 4/4] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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 > >

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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.

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

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

Re: [PATCH v29 00/20] Intel SGX foundations

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

Re: [PATCH v29 00/20] Intel SGX foundations

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

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

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

Re: [RFC PATCH v1 2/3] LSM/x86/sgx: Implement SGX specific hooks in SELinux

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.

Re: [RFC PATCH v1 2/3] LSM/x86/sgx: Implement SGX specific hooks in SELinux

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

Re: [PATCH v20 15/28] x86/sgx: Add the Linux SGX Enclave Driver

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

Re: [RFC PATCH v1 2/3] LSM/x86/sgx: Implement SGX specific hooks in SELinux

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,

Re: [PATCH v29 00/20] Intel SGX foundations

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

Re: [PATCH v29 00/20] Intel SGX foundations

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

Re: [PATCH v29 00/20] Intel SGX foundations

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.

Re: [PATCH v29 00/20] Intel SGX foundations

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

Re: [PATCH v33 12/21] x86/sgx: Allow a limited use of ATTRIBUTE.PROVISIONKEY for attestation

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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 > >

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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.

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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: > > > >

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

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

Re: [RFC PATCH v3 0/4] x86: Add exception fixup for SGX ENCLU

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,

Re: [RFC PATCH v3 0/4] x86: Add exception fixup for SGX ENCLU

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

Re: x86/sgx: uapi change proposal

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

Re: [PATCH v13 02/13] x86/cpufeature: Add SGX and SGX_LC CPU features

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

Re: [PATCH v13 10/13] x86/sgx: Add sgx_einit() for initializing enclaves

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,

Re: [PATCH v20 00/28] Intel SGX1 support

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

Re: [PATCH v20 00/28] Intel SGX1 support

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

Re: [PATCH v20 00/28] Intel SGX1 support

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 > >

Re: [PATCH v20 00/28] Intel SGX1 support

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

Re: [PATCH v20 00/28] Intel SGX1 support

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

Re: [PATCH v20 00/28] Intel SGX1 support

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

Re: [PATCH v19,RESEND 24/27] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions

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.

Re: x86/sgx: uapi change proposal

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

Re: [RFC PATCH v2 4/4] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions

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

Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()

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

Re: [RFC PATCH 00/30] ima: Introduce IMA namespace

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

Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()

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

Re: [RFC PATCH 00/30] ima: Introduce IMA namespace

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

Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()

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

Re: [PATCH v40 10/24] mm: Add 'mprotect' hook to struct vm_operations_struct

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

Re: [PATCH v41 10/24] mm: Add 'mprotect' hook to struct vm_operations_struct

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

Re: [PATCH v40 10/24] mm: Add 'mprotect' hook to struct vm_operations_struct

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

Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()

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

Re: [PATCH v39 15/24] x86/sgx: Add SGX_IOC_ENCLAVE_PROVISION

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

Re: [PATCH v40 10/24] mm: Add 'mprotect' hook to struct vm_operations_struct

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

Re: [PATCH v40 00/24] Intel SGX foundations

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

Re: [PATCH v40 10/24] mm: Add 'mprotect' hook to struct vm_operations_struct

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

Re: [PATCH v40 00/24] Intel SGX foundations

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

Re: [PATCH v40 00/24] Intel SGX foundations

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

Re: [PATCH v40 10/24] mm: Add 'mprotect' hook to struct vm_operations_struct

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

Re: [PATCH v40 10/24] mm: Add 'mprotect' hook to struct vm_operations_struct

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

Re: [PATCH v40 10/24] mm: Add 'mprotect' hook to struct vm_operations_struct

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 > >

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

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

Re: [RFC PATCH v1 2/3] LSM/x86/sgx: Implement SGX specific hooks in SELinux

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

Re: [RFC PATCH 00/30] ima: Introduce IMA namespace

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

Re: [RFC PATCH 00/30] ima: Introduce IMA namespace

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

Re: [PATCH v36 23/24] docs: x86/sgx: Document SGX micro architecture and kernel internals

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

ANNOUNCE: Hugepage (HPD) block device driver.

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 Izzy. As always, Dr

Re: [Scst-devel] ANNOUNCE: Hugepage (HPD) block device driver.

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 ignorance

Re: [PATCH 1/3] pmem: Initial version of persistent memory driver

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 ross.zwis...@linux.intel.com PMEM is a new driver that presents a reserved range of memory as a

Re: [PATCH 0/6] Intel Secure Guard Extensions

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

Re: [PATCH 0/6] Intel Secure Guard Extensions

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" <g...@enjellic.com> wrote: &

Re: [PATCH 0/6] Intel Secure Guard Extensions

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

Re: [PATCH 0/6] Intel Secure Guard Extensions

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

Re: [PATCH 0/6] Intel Secure Guard Extensions

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

Re: [PATCH] tpm: Restore functionality to xen vtpm driver.

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 mul

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

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

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

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

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

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

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

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 >

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

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

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

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/tbo

[PATCH] tpm: Restore functionality to xen vtpm driver.

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: <sta...@vger.kernel.org> # 4.1- Suggested-by: Daniel De Graaf <dgde...@tycho.nsa.gov> Signed-off-by: Dr. Greg Wettstein <g...@enje

Re: [PATCH v2 6/7] tpm: expose spaces via a device link /dev/tpms

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

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

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

[PATCH] tpm: Restore functionality to xen vtpm driver.

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 <g...@enjellic.com> --- drivers/char/tpm/xen-tpmfront.c | 2 +- 1 file changed, 1 insertion(+), 1 delet

Re: [RFC 04/11] ima: add support to namespace securityfs file

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.

Re: [PATCH v6 00/11] Intel SGX Driver

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

Re: [PATCH v6 00/11] Intel SGX Driver

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.

Re: [PATCH v6 00/11] Intel SGX Driver

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

Re: Avoid speculative indirect calls in kernel

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

  1   2   >