linux-kernel - Re: [PATCH 0/4] selftests/sgx: Harden test enclave

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:   Thu, 20 Jul 2023 22:57:41 +0200
From:   Jo Van Bulck <jo.vanbulck@...kuleuven.be>
To:     Dave Hansen <dave.hansen@...el.com>,
        Jarkko Sakkinen <jarkko@...nel.org>, linux-sgx@...r.kernel.org,
        linux-kernel@...r.kernel.org
Cc:     dave.hansen@...ux.intel.com
Subject: Re: [PATCH 0/4] selftests/sgx: Harden test enclave

On 20.07.23 21:56, Dave Hansen wrote:
> On the other hand, if we don't leave glaring, known "security"
> vulnerabilities in it, even more people will be fooled into trying to
> use our example code for something that needs actual security.

I see the reasoning, but I'm afraid it's generally hard to stop people 
from copying good examples as templates for their own projects..

I do believe in the value of clean, minimal open-source example enclave 
code. In this respect, I personally (and others on the past mailing list 
as well, it seems) really like the minimal self-contained Linux selftest 
enclave! I think, with the fixes in this patch series, the Linux 
selftest enclave can continue to bring value to the community and help 
in further diversifying the open-source SGX ecosystem.

FWIW, I'd not call these "glaring" security holes, but rather subtle 
oversights that I think most people who would copy the code today may 
well not be aware of and inherit unknowingly (e.g., reference [2] from 
my original message did a wide-scale study of the open-source SGX 
ecosystem as of 2019 and showed exactly these kinds of ABI/API 
vulnerabilities were widespread and re-occurring in several SGX 
production projects).

> I personally don't know the first thing about writing a secure enclave.
> I just know it's _really_ hard and I honestly don't expect someone to do
> it without the help of the SDK.

Agreed, it _is_ hard indeed. And it has been a moving target over the 
years, especially with software/compiler defenses for different waves of 
microarchitectural vulnerabilities (Spectre, LVI, etc.). That being 
said, I do think that we learned a lot as a community and we have a much 
better grasp on how to write (reasonably) secure enclave software these 
days. Sanitizing the ABI and API remains a core enclave software 
responsibility (whereas microarchitectural attacks can arguably be 
mostly mitigated through hardware silicon/ucode patches and/or automatic 
compiler mitigations).

I do agree that sane end users should use a shielding runtime to 
abstract away most of these concerns, where the Intel SGX SDK is just 
one of many in a growing open-source SGX ecosystem (see for instance 
earlier references [2,3] for an overview).

But there may be good reasons to want to do things from scratch when 
building your own SGX shielding runtime, e.g., support for custom 
languages (Rust, Go) or library OSs. I think the Linux selftest enclave 
helps in further diversifying the open-source SGX ecosystem and can 
provide an excellent starting point (with the fixes in this patch series).

Best,
Jo