Mastodawn

"Enabling Integrity Measurement for Secure Applications in the #Enarx Framework" by Jacopo Catalano, Enrico Bravi, Silvia Sisinni, and Antonio Lioy https://link.springer.com/article/10.1007/s10922-025-09983-4 #ConfidentialComputing

Enabling Integrity Measurement for Secure Applications in the Enarx Framework - Journal of Network and Systems Management

The Cloud Computing paradigm has significantly spread thanks to the high-speed Internet connection, standardization of digital technology, and the wide adoption of mobile devices. As a result, several privacy-enhancing technologies have been developed, among which Confidential Computing aims to protect data in use. Among the various solutions proposed for Confidential Computing, the Trusted Execution Environments (TEE) is becoming increasingly adopted, even in industrial scenarios, providing a shielded area where data and code can be processed and stored. However, heterogeneous TEE technologies are now available, making trusted application development difficult for developers. To overcome the problem of developing and deploying applications caused by the deep differences between the currently available TEE technologies, the project Enarx has been proposed. Enarx permits application development for various TEE instances in the public cloud, being CPU-architecture independent and guaranteeing the security of applications from cloud providers. The Enarx logic loads an application attesting the hardware and the Enarx components but misses the integrity verification of the user-developed application. Therefore, the primary objective of our work is to propose an extension where Enarx can verify the user application’s trustworthiness deployed in underneath the TEE. The next objective is to integrate the extended Enarx framework with the Trust Monitor system, a centralized monitoring and reporting solution to assess the trustworthiness of a heterogeneous critical infrastructure, like the cloud environment. A validation phase has been conducted, proving the solution fulfils the defined goals in terms of functionalities and performance.

SpringerLink

Jarkko Sakkinen Jul 27, 2024

Cool got some response from rust-vmm/vm-memory people, asking to give more details, which I will provide next week.

#Enarx is a kind of hybrid #VMM, and I think this is exactly where I think the overall rust-vmm umbrella has the best opportunities. I.e. instead of just hosting guests with QEMU you might want to do a tailored VMM below to get the optimal characteristics in performance, security and whatnot for your use case.

Enarx hosts #WebAssembly payloads in confidential computing environment. To realize those it:

Uses #KVM API to bootstrap wasm run-time inside a #AMD SEV-SNP VM.

Uses /dev/sgx to partition address space for boostrapping a wasm run-time inside an #Intel SGX enclave.

The first one is very surgically constructed VM with all access outside it disable, and the second is not actually VM at all.

My take is here that any commercially viable memory API should first of all scale to all possible types on VM’s, and also address stuff “on the edges of universum”, e.g. SGX enclaves, which in many ways resemble VM’s (at least to some level).

#Linux #Rust #rustlang

Jarkko Sakkinen Jul 20, 2024

Submitted some ideas to rust-vmm/vm-memory how it should be extended to work for confidential (#SGX, #SNP and #TDX) payloads to make it scale for the needs of #Enarx:

https://github.com/rust-vmm/vm-memory/issues/291

#linux #kvm #rust #rustlang

Extend to confidential computing · Issue #291 · rust-vmm/vm-memory

Motivation for this is written down here: enarx/enarx#2580 Mappings identified from Enarx sources: mmap(): anonymous RW mmap(): anonymous with 0 permissions (SGX). mmap(): MAP_FIXED with arbitrary ...

GitHub

Jarkko Sakkinen Jul 20, 2024

`mmap` struggles with #Rust: https://github.com/enarx/enarx/issues/2580

#enarx #rustlang

[Feature]: memory mapped IO with `vm-memory` · Issue #2580 · enarx/enarx

Is there an existing issue for this? I have searched the existing issues Description Motivation Enarx has multiple internal crates in their own repositories, which are not actively maintained. One ...

GitHub

Jarkko Sakkinen Jul 16, 2024

Compiled #enarx first time for a long time. I'm looking into how feasible it would be to switch the ad-hoc mmap abstraction to rust-vmm/vm-memory crate. #Rust #rustlang

Jarkko Sakkinen May 2, 2024

Posted #enarx issue: https://github.com/enarx/enarx/issues/2580 #rust #rustlang

[Feature]: memory mapped IO with `vm-memory` · Issue #2580 · enarx/enarx

GitHub

Enarx Project Feb 22, 2024

#Enarx's two companion applications, Steward https://github.com/enarx/steward & Drawbridge https://github.com/enarx/drawbridge have been relicensed as Apache 2!

GitHub - enarx/steward: A Confidential Computing-Aware Certificate Authority

A Confidential Computing-Aware Certificate Authority - enarx/steward

GitHub

Jarkko Sakkinen Dec 12, 2023

It is 2023 but for me #Github runners are new, flashy and exciting thing. I put some for my #zmodem2 crate ( basic CI tests).I discovered these functionalities for the first time in 2022 while at #Profian, and working on #Enarx.

I was thinking that I could start to mirror my kernel.org tree to GIthub just to run some CI but can you disable PR's completely? If not, then I think I pass . What about #Gitlab?

Have not used Gitlab that much David (Howells) just set me up access for keyutils repository so have to learn to use it more.

What has turned me away so far from Gitlab is that already Github is sometimes really feeling like someone was drilling a hole through my head and Gitlab on surface looks to have even more all kinds of weird controls and looks somewhat scary but perhaps the real truth is different than my prejudice :-)

Akkoma

Jarkko Sakkinen Nov 30, 2023

One thing that I had to dig up from previous #Enarx work was core::marker::PhantomData. It is not so well known but pretty important concept inside Rust.

PhantomData is a zero-sized struct that merely acts as a life-time indicator for the other parameter, which are usually pointers on where it is applied. It is used to implement many of the core structs such as Rc to name one instance.

It is pretty good lesson on how lifetime parameters interact with the Rust compiler.

I’d even say that if you understand PhantomData, then you have the basic understanding of Rust, and if not, you still have to learn a bit. It is the block that the whole core library is based on after all.

#rustlang

Akkoma

Jarkko Sakkinen Nov 30, 2023

All the crates that #Google has done for #Rust seem to be like stuff I’ve been looking for to get better control of the memory.

Especially zerocopy is a time saver as it has all the thinkable stuff that I have used previously core::slice::from_raw_parts and spent a lot of time thinking of all the possible safety scenarios, such as this recent one:

impl<'a> From<&'a Header> for &'a [u8] {
    fn from(value: &Header) -> Self {
        // SAFETY: out-of-boundary is not possible, given that the size constraint
        // exists in the struct definition. The lifetime parameter links the lifetime
        // of the header reference to the slice.
        unsafe { from_raw_parts((value as *const Header) as *const u8, size_of::<Header>()) }
    }
}

Previously I’ve had to do similar consideration in the #Enarx project. You can do these by hand but it is nice to have a common crate, which is tested by many for these risky scenarios.

Other mentionable crate from Google is tinyvec, which I’m going to use in zmodem2 to remove internal heap usage.