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]
Message-ID: <09ebfa1d-c03d-c1fe-ff0f-d99287b6ec3c@intel.com>
Date:   Thu, 18 Apr 2019 11:01:00 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     "Dr. Greg" <greg@...ellic.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc:     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 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?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ