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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 19 Apr 2019 09:17:32 -0500
From:   "Dr. Greg" <greg@...ellic.com>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
        x86@...nel.org, linux-sgx@...r.kernel.org,
        akpm@...ux-foundation.org, sean.j.christopherson@...el.com,
        nhorman@...hat.com, npmccallum@...hat.com, serge.ayoun@...el.com,
        shay.katz-zamir@...el.com, haitao.huang@...el.com,
        andriy.shevchenko@...ux.intel.com, tglx@...utronix.de,
        kai.svahn@...el.com, bp@...en8.de, josh@...htriplett.org,
        luto@...nel.org, kai.huang@...el.com, rientjes@...gle.com
Subject: 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 the driver, sometime in the future, suffer from being dependent on
> > discretionary access controls, ie. file privileges, that can be
> > defeated by a privilege escalation attack.  Those of us building
> > architectures on top of this technology have a need to certify that an
> > application will provide security contracts robust in the face of a
> > privilege escalation event or platform compromise.

> I'm not following.
>
> Are you saying that the implementation here is too permissive with
> the enclaves that are allowed to run?  Because it's too permissive,
> this leaves us vulnerable to SGX being used to conceal a cache
> attack?

I believe that would be the conclusion of a dispassionate observer who
has followed this conversation and read the paper that I provided a
link to.

For the benefit of those with a disinclination to read, particularly
16 page research papers, the following link provides a summary of the
issues at hand.

https://www.securityweek.com/intel-sgx-can-be-abused-hide-advanced-malware-researchers

Of relevance to this conversation is Intel Security's official
response to the paper, which is as follows:

"The value of Intel SGX is to execute code in a protected enclave;
however, Intel SGX does not guarantee that the code executed in the
enclave is from a trusted source.  In all cases, we recommend
utilizing programs, files, apps and plugins from trusted sources,"
Intel said.

The issue is not as much the ABI break but the following facts that
are at hand:

1.) The proposed mainline driver offers no cryptographic or
architecturally relevant security controls for ensuring that enclaves
are from a trusted source.

2.) Based on Andy's comments there may be a disinclination to ever
provide those controls.

3.) The approach we propose addresses these issues while imposing no
functional limitations on how Linux platform owners can use enclave
technology.

Seems like a win.

There you go, one sentence replies.

Dr. Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@...ellic.com
------------------------------------------------------------------------------
"Laugh now but you won't be laughing when we find you laying on the
 side of the road dead."
                                -- Betty Wettstein
                                   At the Lake