AMD SEV Virtual Machine Support

It looks like AMD-SEV is completely broken: https://arxiv.org/pdf/2108.04575.pdf, also posted here: Long term R&D: TEE enhanced IC (proposal) - #10 by lastmjs

1 Like

Hello, sorry for the late reply. We have been focusing on bringing SEV-SNP enabled nodes on the BTC subnet. Here is the current plan and status:

  1. Complete SEV-SNP design - ongoing
  2. Move ahead with qualifying more Gen-2 hardware - ongoing
  3. Bring Gen-2 hardware to the IC (and BTC subnet in particular)
  4. Enable SEV-SNP for BTC subnet nodes.

We will keep the forum updated with the progress.

7 Likes

Will this be the first subnet that has SEV-SNP enabled nodes? Will other subnets soon enable this feature? Exciting stuff!

1 Like

What is the latest update for SEV-SNP?

1 Like

Hello!

We are currently actively working on this!

We are working on (1) rolling out SEV-SNP hardware and (2) developing software to support a SEV-SNP GuestOS.

SEV-SNP is a hardware-based security feature, which means we must test and onboard SEV-SNP enabled nodes. We have just begun onboarding new node providers with SEV-SNP enabled nodes (what weā€™re calling ā€œgen2 node machinesā€). However, these machines are not yet running GuestOS VMs in SEV-SNP mode, as there is much work that must be done first.

Enabling GuestOS to run with SEV-SNP support is not trivial, as:

  • This is still a new technology and is being actively developed.
  • The gen2 SEV machines must interoperate with the gen1 non-SEV machines.
  • When a node enters a subnet and begins communicating with peers, we must perform mutual attestation between each node in the subnet to the joining node to establish trust.
  • The GuestOS upgrade process becomes more complicated. Now, in order to upgrade the GuestOS, an additional SEV-SNP enabled VM must be spun up and go through an attestation process before data can be transferred from the old VM to the new VM.

We are likely still a few months away from the first SEV-SNP enabled GuestOS running in production, but we will give more updates as we get closer!

10 Likes

Thanks for the update! Good luck with all of this work

3 Likes

Hello,

Would like to give an update on our progress.

  1. We have SetupOS and HostOS which are enabled with SEV-SNP and are in the testing phase.
  2. We are refining the design for upgrading the GuestOS. This upgrade process will take care of upgrading both traditional as well as SEV-SNP VMs to a newer(blessed) version of SEV-SNP VMs without compromising the privacy or confidentiality of the data.
  3. We are also working on all the tooling required to enable a SEV-SNP enabled GuestOS.

Stay tuned for more updates :slight_smile:

6 Likes

Any more updates you can share a month later?

1 Like

Update on SEV-SNP Enabled Replicas:

  1. We have GuestOS running as an SEV-SNP VM. Development is going on for mutual attestation between GuestOS VMs.
  2. The GuestOS upgrade design is going through a Security review.
  3. HostOS upgrade work is in the testing phase currently.
  4. We are also working on a more robust end-to-end testing framework for SEV-SNP based SetupOS.
4 Likes

Can you give an update on generally how long the process could be before general mainnet adoption in all subnets?

3 Likes

When will AMD SEV be launched on the mainnet?
Iā€™m looking forward to AMD SEV, as relying solely on vetKD isnā€™t sufficient for managing personal information in an enterprise setting. I have a keen interest in the enterprise sector, and knowing its release date would facilitate my work.

2 Likes

Hi folks,

This is a small update on the state of SEV-SNP.
I recently joined the node team and weā€™ve been reviewing priorities. SEV enabled replicas are a high priority and weā€™ve trimmed the scope of a first release to be:

ā€œWe have an SEV enabled subnet on mainnet that canisters can deploy to and we are able to upgrade hostOS and guestOSā€

For a while we had been discussing how we would convert non SEV replicas running on gen2 hardware to SEV replicas but we took that out of scope for now. For this milestone we are assuming that will create a subnet from fresh nodes.

Roadmap / progress:

  • Weā€™re now able to boot a replica with SEV enabled (building a working kernel and all the associated tools turned out to be trickier than expected).
  • Weā€™re working on the mutual attestation - this is where the blessed replica version is recorded in the NNS along with the measurements and two replicas trying to join a subnet will check each other before establishing a p2p connection.
  • There is a new mainline kernel with SEV support which we want to try - so far weā€™ve been working with an AMD fork which has been relatively unstable.
  • After that we will work on the upgrade process which is rather complex and is just going through our security design review. The ā€œupgrade processā€ is the ability for a replica to upgrade to a new version which requires an attestation before encryption keys are exchanged.

Weā€™re aiming to have this milestone completed by early Q1 - ie an SEV subnet on mainnet.

5 Likes

I understand that there is likely a number of steps and that the focus is currently on SEV on the replica side, but the #1 feature requested when we talk to multimillion-dollar corporations that consider using the IC is ā€œcan I compute over data that the node provider canā€™t see?ā€.

Some simple way to send encrypted data that can only be decrypted inside the enclave and the ability to aggregate state across descriptions for a data set would be highly impactful for how much IC we can sell to enterprise.

5 Likes

Thatā€™s why weā€™re pushing forward with SEV-SNP. Do you have ideas for another simpler way to achieve this @skilesare?

I wish had any competencies on this so I could help! Iā€™m sure you guys have it in hand, just raising my voice so you all know youā€™re kicking butt and doing awesome stuff we all want!

2 Likes

@raymondk
Have you already decided to adopt AMD?

@tokuryoo we have validated AMDā€™s EPYC Milan servers for Gen2 HW specs. Node Provider Machine Hardware Guide - Internet Computer Wiki

1 Like

Thank you for your reply. I understood.

So do you think SEV + vetKD is sufficient? Iā€™m thinking of a use case of publishing packages to npm from IC canisters. I wonder if storing the auth token encrypted with vetKD and decrypting it temporarily inside of the SEV enclaves for pushing to npm is sufficient?

I wonder if the HTTPS encryption would be done inside of the enclave as well.

I agree that vetKD alone is not sufficient for such use cases.
I am hopeful that SEV + vetKD will solve this problem, too. However, I am not familiar with SEV.

1 Like