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:
- Complete SEV-SNP design - ongoing
- Move ahead with qualifying more Gen-2 hardware - ongoing
- Bring Gen-2 hardware to the IC (and BTC subnet in particular)
- 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!
11 Likes
Thanks for the update! Good luck with all of this work
3 Likes
Hello,
Would like to give an update on our progress.
- We have SetupOS and HostOS which are enabled with SEV-SNP and are in the testing phase.
- 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.
- We are also working on all the tooling required to enable a SEV-SNP enabled GuestOS.
Stay tuned for more updates 
6 Likes
Any more updates you can share a month later?
1 Like
Update on SEV-SNP Enabled Replicas:
- We have GuestOS running as an SEV-SNP VM. Development is going on for mutual attestation between GuestOS VMs.
- The GuestOS upgrade design is going through a Security review.
- HostOS upgrade work is in the testing phase currently.
- We are also working on a more robust end-to-end testing framework for SEV-SNP based SetupOS.
5 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