The Linux Foundation Projects
Skip to main content
Category

Blog

Apr 06

Why is Attestation Required for Confidential Computing?

By Blog No Comments

Alec Fernandez (alfernandez@microsoft.com)

At the end of 2022, the Confidential Computing Consortium amended the definition of Confidential Computing. We added attestation as an explicit part of the definition, but beyond updating our whitepaper we did not explain to the community why we made this change.

First off, an attestation is the evidence that you use to evaluate whether or not to trust a Confidential Computing program or environment. It’s sometimes built into a common protocol as in RA-TLS / Attested TLS. In other uses it might be built into the boot flow of a Confidential VM or built into an asynchronous usage like attaching it to the result of a Confidential Process.

To many of us attestation was an implicit part of Confidential Computing architecture. However it is so central to the idea of Confidential Computing that it really needed to be part of the formal definition.

Hardware and software providers have long offered assurances of security and these assurances have oftentimes fallen short of expectations. A historical analysis of the track record for placing trust in individual organizations to protect data raises important questions for security professionals. The recurrence of data breaches has led to understandably deep skepticism of technologies that purport to provide new security protections.

Users desire to see for themselves the evidence that new technologies are actually safeguarding their data.

Attestation is the process by which customers can alleviate their skepticism by getting answers to these questions:  

  • Can the TEE provide evidence showing that its security assurances are in effect?
  • Who is providing this evidence?  
  • How is the evidence obtained?
  • Is the evidence valid, authentic, and delivered through a secure chain of custody?
  • Who judges the evidence? 
  • Is the judge separate from the evidence provider?
  • Who provides the standards against which the evidence is judged?
  • Can evidence assure that the code and data protection claims are in effect? 

Hardware based attestation evidence is produced by a trusted hardware root-of-trust component of the computing environment. The hardware root-of-trust is a silicon chip or a set of chips that have been specifically designed to be highly tamper resistant. Some have been reviewed by researchers at standards organizations such as NIST, NSA, ICO, ENISA and academic institutions around the world and the technical community at large. While a critique of the analyses behind hardware roots of trust is beyond the scope of this paper, we take them to represent the current state of the art in computer security. They represent a significant improvement over available alternatives. See reference material at the end of this blog for more information.

Providing Attestation Evidence

Attestation evidence is delivered in a message containing authentic, accurate and timely measurements of system components such as hardware, firmware, BIOS and the software and data state of the computer being evaluated. Importantly, this attestation evidence is digitally signed by a key known only to the hardware root-of-trust (often the physical CPU) and not extractable. This means that the attestation evidence is secured. It cannot be altered, once it leaves the hardware without the alteration being detected. It is impervious to attacks by the host operating system, the kernel, the cloud platform provider. This eliminates chain of custody concerns as the evidence flows from the producer to the consumer.

Validating the Authenticity of Attestation Evidence

Before examining the attestation evidence, the source of the evidence must be established. This is done by matching the digital signature in the attestation evidence with a certificate issued by the manufacturer of the hardware root of trust, for example the manufacturer of the physical CPU in the computer. If the signature on the attestation evidence matches the manufacturer’s certificate, then this proves that the attestation report was produced by the CPU hardware. This means that if you trust the company that manufactured the hardware, then you can trust the attestation report.

Who Judges the Attestation Evidence? Are they Separate from the Evidence Provider?

Having the attestation evidence delivered in a message that is digitally signed by hardware allows for TEE users to establish for themselves that the security assurances provided by the TEE are in place. This can be done without the provider of the computing infrastructure or intervening parties being able to alter the evidence during delivery.

Attestation evidence is highly technical and oftentimes it is not feasible for an organization to judge the evidence themselves. This is especially true when the organization is not specialized in computing infrastructure security. In cases such as these, having a different entity, a third party with security expertise, evaluate the evidence offers a good balance between security and complexity. In this scenario, the computing infrastructure or device user is implicitly trusting the entity that verifies the attestation evidence (the verifier). In such scenarios, it is imperative for the device user to have access to effective mechanisms to verify the authenticity and reliability of the verifier to ensure that the attestation results produced by the verifier are legitimate and trustworthy.

Who provides the standards against which the evidence is judged?

The attestation evidence contains claims about the physical characteristics and the configuration settings of the execution environment. Examples include:

  • CPU Manufacturer, model and version and identifier.
  • Microcode and firmware version.
  • Configuration settings, e.g., whether memory encryption is enabled.
  • Encryption configuration, e.g., whether a different key is used to protect each individual VM

The values supplied in the attestation evidence are compared against reference values. For example, the firmware supplier might recommend that it be patched to a specific version due to the discovery of a security vulnerability. The attestation evidence will accurately reflect the current firmware version. But who decides which are acceptable firmware versions?

  • Since the firmware is typically the responsibility of the hardware manufacturer and they have intimate knowledge of the details behind its security baseline, they should certainly be consulted.
  • The owner of the device or computing infrastructure should also be consulted since they could be responsible for any risks of data exfiltration.
  • In a public cloud environment, the computing infrastructure provider controls patching the firmware to the hardware manufacturer’s recommended version but they do not make use of the resulting environment. The user of the TEE is responsible for data placed in the environment and must ensure that firmware complies with their security policy

Remote attestation provides a way to evaluate evidence that shows the actual firmware version provided by the TEE. This evidence is provided directly by the hardware on which the TEE is executing and allows the attestation verifier to independently verify when the patching was completed.

More generally, attestation can be used to check whether all available security standards and policies have been met. This practically eliminates the possibility that a configuration error on the part of the computer or device owner will result in a security guarantee being falsely reported. The computer or device owner might be incorrectly configured in a way that goes undetected, but the attestation evidence comes directly from the hardware component that is executing the TEE and so remains accurate.

Relying on Attestation Evidence to Secure a TEE

An example of using attestation to provide data security is secure key release (SKR). One excellent use case for SKR is configuring your key management infrastructure (KMI) to evaluate the attestation evidence against a policy controlled by the verifier which is deemed to be trustworthy owner of the TEE and configuring your KMI to refuse to supply the key needed to decrypt the computer’s OS disk unless the attestation evidence shows the computer to be in compliance. In this example, the attestation evidence is generated when the computer is powered on and sent to the KMI. If the attestation evidence indicates that the TEE is not in compliance with the policy (perhaps because the CPU firmware was not an acceptable version) then the KMI would not release the decryption key to the compute infrastructure and this would prevent data from being decrypted and this prevent the risk of data exfiltration.

Conclusion

Confidential computing, through the use of hardware-based, attested TEEs and remote attestation protects sensitive data and code against an increasingly common class of threats occurring during processing while data is in use. These were previously difficult, if not impossible to mitigate. Additionally, Confidential Computing allows for protecting data against the owner of the system and public cloud platforms which traditionally had to simply be trusted to not use their elevated permissions to access the data.

 

References

https://nvlpubs.nist.gov/nistpubs/ir/2022/Nist.IR.8320.pdf

https://tools.ietf.org/html/draft-ietf-rats-architecture

CCC-A-Technical-Analysis-of-Confidential-Computing-v1.3_Updated_November_2022.pdf (confidentialcomputing.io)

Common-Terminology-for-Confidential-Computing.pdf (confidentialcomputing.io)

CCC_outreach_whitepaper_updated_November_2022.pdf (confidentialcomputing.io)

Mar 06

Unifying Remote Attestation Protocol Implementations

By Blog, Featured Article No Comments

Shanwei Cen (@shnwc), Dan Middleton (@dcmiddle)

We’re excited to announce some recent attestation news. One of the hallmarks of confidential computing is the ability to build trusted communication with an application running in a hardware-based trusted execution environment. To make attestation easily accessible it can be incorporated into common protocols. That way developers don’t need to figure out all the details to build a secure protocol themselves. One of these protocols is called Remote Attestation TLS (RA-TLS), which builds on the ubiquitously used Transport Layer Security protocol underlying most secure internet communication. It turns out several projects independently implemented RA-TLS with tiny but incompatible differences. In the CCC Attestation SIG, we’ve agreed on and, in some cases, already implemented changes to make them all be able to interoperate.

The CCC Attestation SIG is chartered to develop attestation-related software aimed at improving interoperability, and to achieve harmonization and de-fragmentation between multiple projects. One approach is to identify and review projects in SIG meetings, propose improvements for interoperability and standardization, and work with these projects for implementation and tests. Interoperable RA-TLS is a great example showcasing how the SIG delivers on its charter.

RA-TLS (Remote Attestation TLS) architecture is defined in the white paper Integrating Remote Attestation with Transport Layer Security, to enable Intel® Software Guard Extensions (Intel® SGX) remote attestation during the establishment of a standard Transport Layer Security (TLS) connection. In a TLS server / client scenario, the TLS server runs inside an SGX enclave. It generates a public-private keypair, creates an SGX report with a hash of the public key in its user-data field, and gets an SGX quote for this report. It then creates an X.509 certificate with a custom extension containing this SGX quote. This customized certificate is sent to a TLS client in the TLS handshake protocol. The client gets the SGX quote from the certificate and performs remote attestation to verify that the connected server runs inside an authentic Intel® SGX enclave.

There are a few aspects of RA-TLS architecture that were not covered in this white paper. Some of the gaps include the specific X.509 extension OID value for the SGX quote, the supported types of SGX quote, and how the public key is hashed. Additionally, since the white paper was published, new TEEs like Intel® Trust Domain Extensions (Intel® TDX) and new quote formats have become available. The level of specificity in the RA-TLS paper left room for incompatibility between different implementations and prevented their interoperability.

RA-TLS has been supported in multiple open-source projects, including Gramine, RATS-TLS, Open Enclave Attested TLS, and SGX SDK Attested TLS. The CCC Attestation SIG invited these projects to its meetings for review, and recommended further investigation to look into harmonization between them for interoperability. Following up on this recommendation, we conducted an in-depth investigation and identified areas of incompatibility. We documented our findings, created a draft proposal for an interoperable RA-TLS architecture, and presented our work back to the SIG.

Based on the interoperable RA-TLS draft proposal, we refined the design, and aligned it with the upcoming DICE Attestation Architecture v1.1 draft standard on X.509 extension OID value and evidence format definition (as a tagged CBOR byte string). We created an CCC Attestation SIG github project interoperable-ra-tls to host the design documents and interoperability tests. This project also facilitates discussion among members of the RA-TLS projects and the CCC Attestation SIG community in general. In addition, we registered the needed CBOR tags with the IANA registration service. In the process, we provided feedback to the DICE Attestation Architecture workgroup for refinement of their draft standard specification.

Great progress has been made to implement this proposed interoperable RA-TLS scheme in the RA-TLS projects. We’ve worked with all the projects to create issues and pull requests for their implementations. Especially, as discussed in some of the interoperable-ra-tls project issues, Gramine and RATS-TLS have completed their implementation, and have been active in interoperability tests.

In summary, the interoperable RA-TLS work demonstrated the value of the CCC Attestation SIG in providing a constructive forum to collaborate on attestation technology. We invite you to try out the new unified implementations in Gramine and RATS-TLS. If you are interested in getting more involved, please join us at the CCC Attestation SIG or any other facet of our Confidential Computing Consortium open source community. All are welcome here.

Aug 24

CCC at Black Hat and DEF CON 2022

By Blog, CCC Events No Comments

The Confidential Computing Consortium (CCC) was present at the 25th edition of Black Hat USA and the 30th edition of DEF CON.

At Intel’s booth for Black Hat, there was a big effort towards bringing awareness to Confidential Computing, including the distribution of outreach material from the Confidential Computing Consortium, as well as sessions from Anjuna (“Confidential Computing 101”) and Fortanix (“Confidential Computing AI & Intel SGX: accelerating the use of AI/ML”).

One of the highlights of Black Hat was the responsible disclosure of the ÆPIC Leak by researchers Pietro Borrello (Sapienza University of Rome) and Andreas Kogler (Graz University of Technology) and their collaboration with Intel to mitigate the vulnerability. After their session at Black Hat, the researchers and their colleagues met with the Confidential Computing Consortium representatives and shared how they worked closely together with Intel to follow responsible vulnerability disclosure practices. Intel has provided a microcode update for processors with Intel SGX to enable support to clear buffers and mitigate potential exposure of sensitive stale data when exiting Intel SGX enclaves.

At DEF CON, the Confidential Computing Consortium was mostly present at the Crypto and Privacy Village, which provides a forum for the hacker community to share knowledge and discuss cryptography and privacy.

Community members of the Enarx project gave two talks at the Crypto and Privacy Village: “Owned or pwned? No peekin’ or tweakin’!” and “Cryptle: a secure multi-party Wordle clone with Enarx”. The talks were presented by Richard Zak, Tom Dohrman, and Nick Vidal, with assistance from Ben Fischer from Red Hat.

We would like to thank attendees and organizers of Black Hat, DEF CON, the Crypto and Privacy Village, as well as staff and members of the Confidential Computing Consortium, including representatives from Anjuna, Fortanix, Intel, Profian, and Red Hat/IBM.

Jul 20

Response by the CCC to the Office of Science and Technology Policy’s RFI on Advancing Privacy-Enhancing Technologies

By Blog No Comments

July 7, 2022

To Whom It May Concern:

Please consider the following submission to the Request for Information on Advancing Privacy-Enhancing Technologies from the Confidential Computing Consortium. The Confidential Computing Consortium (https://confidentialcomputing.io) is a Linux Foundation project “to accelerate the adoption of Trusted Execution Environment (TEE) technologies and standards” and has a diverse membership of hardware and software vendors and cloud service providers (https://confidentialcomputing.io/members/). This response was prepared by the group’s Technical Advisory Council with participation from across the membership, and ratified by its Governing Board. The Linux Foundation is a non-profit organization registered in the United States as a 501(c)(6).

The Confidential Computing Consortium has a mandate to engage with governments, standards agencies and regulatory agencies to encourage adoption of Confidential Computing, as well as work with the larger ecosystem and engage with existing and potential end-users of the technologies. It also works with open source projects to further development of implementations. The Confidential Computing Consortium is committed to encouraging open source implementations of Confidential Computing technologies to ensure wide-spread adoption, scalable community involvement, transparency of process, increased security and ease of auditing by relevant interested parties and authorities.

The Confidential Computing Consortium welcomes collaboration with governmental and non-governmental organizations and has mechanisms in place to provide appropriate membership, as well as open technical participation without any membership requirement.

Sincerely,
Stephen R. Walli
Confidential Computing Consortium, Governing Board Chair

Read the response here.

Jul 18

Roadsec: LATAM’s largest hacker conference

By Blog No Comments

The Confidential Computing Consortium (CCC) was one of the 10 communities selected to be part of Roadsec, LATAM’s largest hacker conference. Over 5000 participants were present at this in-person conference held in Sao Paulo.

Roadsec started as meetups about cyber-security that were organized across different cities (thus the name Roadsec, as speakers were always on the road). Every year the community gathers in Sao Paulo for the main conference.

Sao Paulo is considered an alpha global city and serves as Latin America’s financial and technological hub. Major banks and cloud service providers have their headquarters and data centers in this city.

Nick Vidal, CCC’s Outreach Committee Co-Chair, was at the conference promoting the CCC and also inviting participants to the Cryptle Hack Challenge, a secure multi-player Wordle clone that demonstrates how Confidential Computing works.

Roadsec organizers were kind enough to provide the CCC a booth to present this emerging technology called Confidential Computing, which protects data in use by performing computation in a hardware-based Trusted Execution Environment. These secure and isolated environments prevent unauthorized access or modification of applications and data while in use, thereby increasing the security assurances for organizations that manage sensitive and regulated data.

Recently, there have been many serious cyber attacks in Brazil, including the leakage of sensitive patient data from DATASUS and sensitive client data from Banco Pan. Confidential Computing could have helped prevent these data leakages.

May 27

CCC Project Updates

By Blog No Comments

Check out what the CCC Projects have been up to!

Gramine

Gramine project (formerly known as Graphene) will release a new stable version v1.2 in upcoming weeks.

Gramine is a library OS that enables protecting sensitive workloads with Intel® Software Guard Extensions (Intel® SGX). Gramine runs unmodified Linux applications on Intel® SGX out of the box and provides all functionality required for end-to-end protection of workloads: remote SGX attestation, transparent encryption of security-critical files, secure multi-processing. Gramine follows a “lift-and-shift” paradigm for running unmodified applications: to “graminize” the application, it is enough to write a so-called *manifest* file that reflects a runtime configuration of the protected application. Gramine also supports Docker integration via a tool called Gramine Shielded Containers (GSC) and provides a growing set of curated applications, runtimes and frameworks.

In comparison to the previous release, Gramine v1.2 introduces a major overhaul of the FS subsystem. In particular, the Protected Files (PF) feature was significantly reworked. A new manifest syntax allows to mark whole FS mounts for encryption. The PF feature is now available not only in the SGX mode of Gramine, but also in the direct mode, for ease of debugging. We also added support for renaming PFs, memory mapping them with read-write permissions and encrypting them with different user-supplied encryption keys. As a side effect of this rework, multiple bugs in the FS and PF subsystems were fixed.

Additionally, Gramine v1.2 introduces a final reworked CPU/NUMA topology feature (previously marked as experimental). Now, CPU/NUMA topology is securely forwarded inside a Gramine SGX enclave and enabled by default. Among other improvements in Gramine, we highlight better support for CentOS/Fedora/RHEL Linux distributions and the update of the EPID SGX attestation tools to use IAS API v4. We also added a Rust example (a simple web server that uses hyper and tokio crates), as well as a new Python example for SGX quote retrieval.

Along with this technical work, Gramine was presented in different forums and featured in articles and blog posts:

– Gramine talk at the FOSDEM’22 conference: https://fosdem.org/2022/schedule/event/tee_gramine/

– Gramine talk at a Confidential Computing Consortium (CCC) webinar:  https://confidentialcomputing.io/webinar-gramine/

– Highlighted in several use cases and projects at the Open Confidential Computing Conference (OC3 2022) conference: https://www.oc3.dev/program

– Integration with Open Federated Learning (OpenFL) framework: https://medium.com/openfl/a-path-towards-secure-federated-learning-c2fb16d5e66e

– Integration with IBM/Gematik e-Prescription solution: https://github.com/eRP-FD/vau-base-image

– Reference solutions with Gramine as part of the Confidential Computing Zoo (CCZoo): https://github.com/intel/confidential-computing-zoo

– Whitepaper “Computation offloading to hardware accelerators in Intel SGX and Gramine Library OS”: https://arxiv.org/abs/2203.01813

– Blog post “How Open Source Gramine Accelerates Expanding Confidential Computing Market”: https://www.linkedin.com/pulse/how-open-source-gramine-accelerates-expanding-confidential-mona-vij/?trk=articles_directory

– A series of technical blog posts: https://gramineproject.io/blog/

For more information on the release please check out: https://github.com/gramineproject/gramine/releases/tag/v1.2

We invite you to join the Gramine community and contribute to adoption of confidential computing through open source collaboration. We also look forward to your feedback as you deploy this latest release of Gramine for your solutions.

Enarx

The Enarx project had three releases this quarter:

– Enarx 0.3.0 (Chittorgarh Fort) released in March with TLS support, attestation & validation support (https://blog.enarx.dev/chittorgarh-fort/).

– Enarx 0.4.0 (Fort of Dhat al-Hajj) released in April with SGX2 support, improved TLS support, and much more (https://blog.enarx.dev/enarx-0-4-0-fort-dhat-al-hajj/).

– Enarx 0.5.0 (Elmina Castle) released in May with many new/improved features: New enarx deploy subcommand. SGX with EDMM / SGX2 support (https://blog.enarx.dev/elmina-castle/).

In addition to Linux, Enarx is now available on MacOs, Windows, and Raspberry Pi:

– Enarx can now be compiled on additional platforms in a light development version. From MacOS to Raspberry Pi — Extending the Enarx Development Platforms.  (https://blog.enarx.dev/backend-nil/)

The Enarx project announced the Cryptle Hack Challenge:

– Cryptle is a secure multi-player clone of Wordle. The goal of the Cryptle Hack Challenge is to uncover vulnerabilities in the Enarx project. (https://blog.enarx.dev/cryptle-hack-challenge/).

The Enarx community has achieved a huge milestone: we have collectively published 100 tutorials and articles over at Wasm Builders!

– As part of the Confidential Computing Fellowship program, the Enarx project has received several mentees from Outreachy and LFX Mentorship. Wasm Builders has served as a welcoming environment where Enarx community members can share their learning experiences with others (https://blog.enarx.dev/enarx-community-reachs-100-tutorials/).

The Enarx project has participated in the following events:

– Nathaniel McCallum presented “WASI Networking” at Wasm Day at KubeCon + CloudNativeCon Europe 2022 (https://blog.profian.com/wasm-day-at-kubecon-cloudnativecon-europe-2022/).

– Outreachy intern Shraddha Inamdar presented “Enarx: The Platform Abstraction for Trusted Execution Environments” at FOSSASIA (https://enarx.dev/resources/2022-04-09-fossasia).

– CCC Fireside Chat: Stephen Walli received Mike Bursell to discuss his book “Trust in Computer Systems and the Cloud,” with a particular focus on the impact of Confidential Computing on security, trust and risk (https://blog.profian.com/trust-in-computer-systems-and-the-cloud/).

Veracruz

  • We recently announced our 22.05 release which included first-time contributions from several people including Aryan Godara, Mohamed Abdelfatah, and Sagar Arya.  Many of these contributions focussed on adding new examples to the Veracruz repository.  Mohamed will be joining us as our Outreachy-sponsored intern shortly, working on providing better documentation of the expected behavior of Wasi system calls (https://github.com/veracruz-project/veracruz/releases/tag/veracruz-2205).
  • We’ve worked to simplify Veracruz attestation further, across all of our supported platforms, making the process more uniform and removing platform-specific quirks.
  • We’ve started work, and are progressing quickly, on supporting seL4 as an in-enclave operating system for ultra-low TCB enclaves.
  • We’ve worked to improve Veracruz documentation.
  • Many other smaller bug fixes, performance improvements, and upgrades of dependencies to fix security concerns.
Jan 24

CCC Project Updates

By Blog No Comments

Check out what the CCC Projects have been up to!

Gramine

Following the first production-ready release “v1.0”, The Gramine Project is releasing “v1.1” in upcoming weeks. One highlight of this release is stability improvements for Golang and Rust workloads. Another prominent feature of the release is support for the musl C standard library – now Gramine allows users to choose between glibc and musl, depending on users’ requirements on the binary size (TCB), as musl is more light-weight than glibc. Also, AddressSanitizer was integrated in Gramine, and it runs in the CI on each change, for detecting any security issues ahead of code merge. This version adds several other features as well as multiple bug fixes (thanks to our ever-increasing user base for reporting issues!).

While there are several use cases under development, we would like to highlight the production release of the OpenVino Security Add-on (OVSA) for Model IP protection (consider using it for your protected ML workloads). Please reach out to the Gramine team if you are experimenting with Gramine and would like to be added to the list of “Users of Gramine”

Enarx

In Enarx’s first release “version .0.1.0” (codenamed Alamo) we provided WebAssembly as a runtime. For our upcoming release “version 0.2.0” this coming quarter we are looking forward to providing support for attestation, including Intel’s SGX and AMD’s SEV.

Other areas where we are working on are support for filesystem and networking, which depend on upstream collaboration with the WebAssembly community.

Enarx is under high development and is not production ready yet, but our hope is that these initial releases will allow developers to experiment with Enarx and see its progress.

If you are interested in learning more about the Enarx project, please access our website, star us on GitHub, and join our chat.

Oct 08

Gramine 1.0 release

By Blog No Comments

Announcing Gramine production ready release!

Having recently joined the Confidential Computing Consortium in the Linux Foundation, The Gramine Project (formerly known as Graphene) is proud to announce the first production-ready version to enable protecting sensitive workloads with Intel® Software Guard Extensions (Intel® SGX).

The project started as a research prototype at Stony Brook University in 2011, and the first open-source version was published in 2014, followed by the Intel® SGX port in 2017 in collaboration with Intel Labs. In December 2018, Golem and ITL joined the project, forming the core of the open source community around the project, including a first release.  The Gramine community has subsequently grown into a diverse group of contributors, from universities, small and large companies, as well as individuals.

Gramine not only runs Linux applications on Intel® SGX out of the box, but also provides several tools and infrastructure components for a push-button lift-and-shift paradigm for running unmodified applications on confidential computing platforms based on  Intel® SGX. Gramine supports both local and remote Intel® SGX attestation, and with both EPID and DCAP schemes. With the protected files feature, security-critical files are automatically encrypted and decrypted inside the enclave. Gramine supports several performance optimizations for Intel® SGX applications including asynchronous system calls. Gramine is one of the few frameworks that supports multi-process applications by providing a complete and secure fork implementation. Gramine supports Docker integration via a tool called Gramine Shielded Containers (GSC) that automatically converts Docker images to Gramine images.  Containers built with GSC can be deployed via Kubernetes for confidential containers and microservices.  Gramine also supports cloud deployment with Azure Confidential VMs and integrates with Azure Kubernetes Services in Azure cloud.

Since our last release, there have been major changes in the code with 1272 files changed, 100637 insertions, 112144 deletions, 1648 commits from 49 authors. This includes a major rewrite of the code that handles features including memory management, thread handling, process handling, filesystem and signal handling. You can find the detailed changelog at our github.  In future, we plan to continue Gramine development with additional features, code cleanup, tooling, and documentation. We also plan to add generic support for I/O device communication as well as add additional Platform Adaptation Layers (PAL) for other TEEs like Intel® TDX.

Gramine has a growing set of well-tested applications including machine learning frameworks, databases, web servers, and programming language runtimes and there are several projects that are already experimenting with Gramine for developing their solutions to protect data in use. We expect that Gramine 1.0 will bring many of those solutions to production. We look forward to your feedback as you deploy this latest version of Gramine for your confidential computing solutions with lift-and-shift capability.

For more information on the release please check out: https://github.com/gramineproject/gramine/releases/tag/v1.0

We invite you to join the Gramine community and contribute to adoption of  confidential computing through open source collaboration.

Oct 06

The Confidential Computing Consortium Year in Review, 2021

By Blog No Comments

We are just finishing the second year of the Confidential Computing Consortium, and it is time once again to look back on what the members have accomplished together. 

Membership & Project Growth

All of our meetings start with the reminder that all members are welcome and all projects are welcome. It have been this way since we launched. 

Remember that companies create non-profits like the Consortium in the broad open source space because our businesses benefit from that membership, and from working together towards common goals. We launched the Consortium with 15 premier and general members, growing to 27 corporate members and 2 non-profits by the end of the first year. While we lost a few members this year as company priorities shift, we have continued to grow to 36 corporate members and 4 non-profits over this past year. 

This year we welcomed the following companies to the Consortium: 

Ampere, Applied Blockchain, Baidu USA, Canary Bit, Cisco, Crust, Edgeless, En|viel, Ethernity Cloud, HUB Security, Madana, Opague Systems Inc, Phalla Network, Technology Innovation Institute, Western Digital, Xilinx. 

Our newest general member last week is Profian. The addition of general members through the year brought us over the twenty mark and we added a new general member representative to the governing board (Eric Voit, Cisco). 

A primary part of our shared mission is to support open source and standards projects relating to confidential computing to accelerate the acceptance and adoption of confidential computing in the market. This year the Consortium welcomed four new projects:

  • Keystone: Keystone is an open-source project for building trusted execution environments (TEE) with secure hardware enclaves, based on the RISC-V architecture. Our goal is to build a secure and trustworthy open-source secure hardware enclave, accessible to everyone in industry and academia.
  • Veracruz: Veracruz is a research project exploring the design of privacy-preserving distributed systems.  Veracruz uses strong isolation technology and remote attestation protocols to establish a “neutral ground” within which a collaborative, multi-party computation between a group of mistrusting principals takes place.
  • Gramine: Gramine is a rebranded Graphene project. A particular use case for Gramine is Intel Software Guard Extensions (SGX), where applications do not work out-of-the-box. Gramine solves this problem, with the added security benefits. Gramine can serve as a compatibility layer on other platforms.
  • Occlum: Occlum makes running applications inside enclaves easy. It allows one to run unmodified programs inside enclaves with just a few simple commands.

The Technical Advisory Council (TAC)

The Technical Advisory Council continues to meet every other week. It is an opinionated public debate and everyone is welcome to attend. Members in the TAC saw the need to begin to add some structure and this year created the idea of Special Interest Groups (SIG) as they put in place the Attestation SIG. It was recognized by members that attestation will become the next challenge in confidential computing and have begun the discussion of how best to enable TEE attestation across the industry. 

The TAC membership also published a more detailed Technical Analysis of Confidential Computing white paper.

The Outreach Committee

Outreach Committee members were also busy this year in their collaboration. The Consortium Webinar Series has been building with monthly entries covering our projects and topics that span our domain. This is a good quick way to get an introduction to projects as each project has contributed to the collection. 

A global pandemic makes it tough to gather together, but this year the members organized and ran the first Confidential Computing Developer Summit, C2DS in June. It was run as a virtual unconference with a full day of content. There was good attendance with 400 registered developers participating through the day. All the feedback was good and the team looks forward to building an event again this coming year. 

The Outreach Committee commissioned an analyst group to produce a market study this year. Working with members, the analysts have built a view of the confidential computing industry in its growth. The study will be published this month. 

Lastly, Outreach Committee members have been working towards launching an End User Advisory Council to attract broader input into how users of confidential computing technology see the challenges ahead. We had hoped to launch the advisory council at the Linux Foundation Open Source Summit in September, but pulled back as people continue to be cautious with pandemic travel. Look for a launch in the near future. 

Outreach is working with the Linux Foundation creative staff to improve the Consortium website and we will be rolling changes out soon.

General Administrivia

I have long joked that governing boards should be boring places voting on meeting minutes, money, and membership. 

  • In keeping with that intent, we continue to run a healthy budget surplus as working committees spend money cautiously in a pandemic. 
  • We reviewed and tuned our charter last year in the Fall. As members continued to evolve our transparent, collaborative endeavor together, they had suggestions for tweaks to the charter that were voted last Fall. We will open the charter again shortly to see what new changes will be proposed. In making this an annual practice, it becomes an easy muscle to exercise, and debates don’t become worrisome and contentious. 

We continue to get great support from the Linux Foundation services teams. Stephano Cetola has recently moved to become a technical director at the RISC-V organization. While we are sad to see him go, Brian Warner is stepping into the role of Linux Foundation program manager. This year Ashley Weltz joined the program management team to help put the developer summit and end user advisory council in place. 

I look forward to continue working with all of our members in the coming year. A number of new projects have approached the Consortium. New members continue to express interest. It should be an exciting year ahead. 

Updated January 2022 to reflect new members joining in Q4 of 2021.

Close Menu