On Fri, 7 Jul 2023, 18:11 1one1 via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

>
> **Document number**: PXXXXR0
> **Date**: 2023-07-07
> **Project**: Programming Language C++
> **Reply to**: ahshabazz
>
> # Proposal to introduce a Hardware Security Namespace to the C++ Standard
> Library
>
> ## Introduction
>
> This paper proposes the addition of a new hardware security namespace to
> the C++ Standard Library to allow developers to better leverage
> hardware-level security features in a platform-independent manner. This
> proposal is intended as a high level architecture agnostic secure compute
> model because as of today both Intel, AMD, and many other vendors have
> introduced various security measures in their hardware, such as Intel's
> Software Guard Extensions (SGX). An API in the C++ standard for these
> features could provide developers with the tools to ensure secure
> computation and data protection.
>
> ## Motivation and Scope
>
> Modern processors from vendors such as Intel and AMD provide various
> hardware-level security features, such as Intel's Software Guard Extensions
> (SGX). And yet currently, there is no standard way in C++ to utilize these
> features, and developers must rely on vendor-specific APIs and tools,
> leading to non-portable code.
>
> By introducing a standard hardware security namespace, we can provide
> developers with a more consistent, abstracted way to use these features and
> improve the security of their applications without sacrificing portability.
>
> The API call and management would be similar to the std::thread API in
> C++11 and later versions, because it is a suitable example of an API which
> uses a similar design pattern, ie.:
>
> Creation: A std::thread object is created by constructing an instance
> of the std::thread class, passing the function to be executed in a new
> thread as a constructor argument. This is in much the same way
> [[secure::enclave]] would work.
>
> Execution: With std::thread, the execution of std::thread starts after
> its creation. However with [[secure::enclave]] there is an explicit
> .execute() call, because the new executing context may immediately be used
> and reused after creation.
>

Does the execution happen in a new thread of execution? Is it detached?
Does it need to be joined? What happens if you call execute twice in a row?
Does it block?


> Destruction: Before a std::thread object is destroyed, you must either
> join it (with std::thread::join()) or detach it (with
> std::thread::detach()), or the program will terminate. [[secure::enclave]]
> would employ a similar .destroy() call.
>

Why is that restriction suitable here?

If the API is so similar to std::thread, why not use the same API? The
changes don't seem sufficiently motivated.


> ## Impact on the C++ Standard
>
> This proposal is purely additive and does not modify any existing parts of
> the C++ Standard. It does not require any changes to the core language.
>
> ## Design Decisions
>
> The proposed namespace, tentatively named `hwsec`, will initially contain
> an attribute to denote functions that should run in a secure context, and a
> class that manages secure contexts. The proposed design is similar to how
> `std::thread` manages threads, but separates resource acquisition and
> execution into separate methods to provide more control to the user.
>
> The API signature could look as follows:
>
> ```
> [[hwsec::enclave]]
> void secureFunction() {
> // Code here runs in a secure enclave //
> std::cout << "Running in a secure enclave." << std::endl;
> }
>
> int main() {
> hwsec::Enclave myEnclave;
>
> try {
> // Create a new enclave //
> myEnclave.create();
>
> // Run a function inside the enclave //
> myEnclave.execute(secureFunction);
>
> // Destroy the enclave //
> myEnclave.destroy();
> }
> catch (const hwsec::Exception& e) {
> std::cerr << "HWSEC error: " << e.what() << std::endl;
> }
>
> return 0;
> }
> ```
>
> ## Future Directions
>
> If accepted, future extensions to the `hwsec` namespace could include
> additional attributes, classes, and functions to support other
> hardware-level security features.
>
> ## Acknowledgments
>
> Thanks to the members of the C++ community for their valuable insights and
> discussions that helped shape this proposal.
>
> ## References
>
> [To be added]
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>