[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a51dde86-b2e5-569a-81ce-78db66986302@cs.kuleuven.be>
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
Powered by blists - more mailing lists