* [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP @ 2023-03-21 9:29 Jörg Rödel 2023-03-21 11:09 ` James Bottomley ` (3 more replies) 0 siblings, 4 replies; 42+ messages in thread From: Jörg Rödel @ 2023-03-21 9:29 UTC (permalink / raw) To: amd-sev-snp, linux-coco, kvm Hi, We are happy to announce that last week our secure VM service module (SVSM) went public on GitHub for everyone to try it out and participate in its further development. It is dual-licensed under the MIT and APACHE-2.0 licenses. The project is written in Rust and can be cloned from: https://github.com/coconut-svsm/svsm There are also repositories in the github project with the Linux host and guest, EDK2 and QEMU changes needed to run the SVSM and boot up a full Linux guest. The SVSM repository contains an installation guide in the INSTALL.md file and contributor hints in CONTRIBUTING.md. A blog entry with more details is here: https://www.suse.com/c/suse-open-sources-secure-vm-service-module-for-confidential-computing/ We also thank AMD for implementing and providing the necessary changes to Linux and EDK2 to make an SVSM possible. Have a lot of fun! -- Jörg Rödel jroedel@suse.de SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-21 9:29 [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP Jörg Rödel @ 2023-03-21 11:09 ` James Bottomley 2023-03-21 12:43 ` Jörg Rödel 2023-03-21 15:06 ` Dr. David Alan Gilbert ` (2 subsequent siblings) 3 siblings, 1 reply; 42+ messages in thread From: James Bottomley @ 2023-03-21 11:09 UTC (permalink / raw) To: Jörg Rödel, amd-sev-snp, linux-coco, kvm On Tue, 2023-03-21 at 10:29 +0100, Jörg Rödel wrote: > Hi, > > We are happy to announce that last week our secure VM service module > (SVSM) went public on GitHub for everyone to try it out and > participate in its further development. It is dual-licensed under the > MIT and APACHE-2.0 licenses. > > The project is written in Rust and can be cloned from: > > https://github.com/coconut-svsm/svsm > > There are also repositories in the github project with the Linux host > and guest, EDK2 and QEMU changes needed to run the SVSM and boot up a > full Linux guest. > > The SVSM repository contains an installation guide in the INSTALL.md > file and contributor hints in CONTRIBUTING.md. > > A blog entry with more details is here: > > > https://www.suse.com/c/suse-open-sources-secure-vm-service-module- > for-confidential-computing/ > > We also thank AMD for implementing and providing the necessary > changes to Linux and EDK2 to make an SVSM possible. Since this a fork of the AMD svsm code (https://github.com/AMDESE/linux-svsm/), is it intended to be a permanent fork, or are you going to be submitting your additions back upstream like we're trying to do for our initial vTPM prototype? From the community point of view, having two different SVSM code bases and having to choose which one to develop against is going to be very confusing ... James ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-21 11:09 ` James Bottomley @ 2023-03-21 12:43 ` Jörg Rödel 2023-03-21 13:43 ` James Bottomley 0 siblings, 1 reply; 42+ messages in thread From: Jörg Rödel @ 2023-03-21 12:43 UTC (permalink / raw) To: James Bottomley; +Cc: amd-sev-snp, linux-coco, kvm Hi James, On Tue, Mar 21, 2023 at 07:09:40AM -0400, James Bottomley wrote: > Since this a fork of the AMD svsm code > (https://github.com/AMDESE/linux-svsm/), is it intended to be a > permanent fork, or are you going to be submitting your additions back > upstream like we're trying to do for our initial vTPM prototype? From > the community point of view, having two different SVSM code bases and > having to choose which one to develop against is going to be very > confusing ... The COCONUT-SVSM was and is a separate project and not a fork of AMDs linux-svsm. Some code was ported from our code-base to linux-svsm in the past, namely the SpinLock implementation and the memory allocators. What the project also shares with linux-svsm is the support code in the Linux kernel (host and guest) and the EDK2 changes needed to launch an SVSM. But besides that the two code-bases are different, using a different build approach and different launch protocol. The goals we have with our SVSM are hard to achieve with the linux-svsm code-base, so a merge does not make sense at this point. Regards, -- Jörg Rödel jroedel@suse.de SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-21 12:43 ` Jörg Rödel @ 2023-03-21 13:43 ` James Bottomley 2023-03-21 15:14 ` Jörg Rödel 0 siblings, 1 reply; 42+ messages in thread From: James Bottomley @ 2023-03-21 13:43 UTC (permalink / raw) To: Jörg Rödel; +Cc: amd-sev-snp, linux-coco, kvm On Tue, 2023-03-21 at 13:43 +0100, Jörg Rödel wrote: > Hi James, > > On Tue, Mar 21, 2023 at 07:09:40AM -0400, James Bottomley wrote: > > Since this a fork of the AMD svsm code > > (https://github.com/AMDESE/linux-svsm/), is it intended to be a > > permanent fork, or are you going to be submitting your additions > > back upstream like we're trying to do for our initial vTPM > > prototype? From the community point of view, having two different > > SVSM code bases and having to choose which one to develop against > > is going to be very confusing ... > > The COCONUT-SVSM was and is a separate project and not a fork of AMDs > linux-svsm. Some code was ported from our code-base to linux-svsm in > the past, namely the SpinLock implementation and the memory > allocators. Well at the time you submitted the pull request, Coconut wasn't public, so I don't think it looked like a port from a separate code base when it happened. But anyway, I'm not so interested in who is based on whom, I'm more interested in how we avoid dividing our efforts on confidential computing going forwards. > What the project also shares with linux-svsm is the support code in > the Linux kernel (host and guest) and the EDK2 changes needed to > launch an SVSM. > > But besides that the two code-bases are different, using a different > build approach and different launch protocol. The goals we have with > our SVSM are hard to achieve with the linux-svsm code-base, so a > merge does not make sense at this point. Could you describe these incompatible goals and explain why you think they are incompatible (as in why you and AMD don't think you can agree on it)? That would help the rest of us understand where the two SVSM implementations fit in our ongoing plans. Regards, James ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-21 13:43 ` James Bottomley @ 2023-03-21 15:14 ` Jörg Rödel 2023-03-21 17:48 ` Dr. David Alan Gilbert 2023-03-21 20:05 ` James Bottomley 0 siblings, 2 replies; 42+ messages in thread From: Jörg Rödel @ 2023-03-21 15:14 UTC (permalink / raw) To: James Bottomley; +Cc: amd-sev-snp, linux-coco, kvm On Tue, Mar 21, 2023 at 09:43:48AM -0400, James Bottomley wrote: > Could you describe these incompatible goals and explain why you think > they are incompatible (as in why you and AMD don't think you can agree > on it)? That would help the rest of us understand where the two SVSM > implementations fit in our ongoing plans. The goal of COCONUT is to have an SVSM which has isolation capabilities within itself. It already has percpu page-tables and in the end it will be able to run services (like the TPM) as separate processes in ring 3 using cooperative multitasking. With the current linux-svsm code-base this is difficult to achieve due to its reliance on the x86-64 crate. For supporting a user-space like execution mode the crate has too many limitations, mainly in its page-table and IDT implementations. The IDT code from that crate, which is also used in linux-svsm, relies on compiler-generated entry-code. This is not enough to support a ring-3 execution mode with syscalls and several (possibly nested) IST vectors. The next problem with the IDT code is that it doesn't allow modification of return register state. This makes it impossible to implement exception fixups to guard RMPADJUST instructions and VMPL1 memory accesses in general. When we looked at the crate, the page-table implementation supported basically a direct and an offset mapping, which will get us into problems when support for non-contiguous mappings or sharing parts of a page-table with another page-table is needed. So in the very beginning of the project I decided to go with my own page-table implementation. Of course we could start changing linux-svsm to support the same goals, but I think the end result will not be very different from what COCONUT looks now. Regards, -- Jörg Rödel jroedel@suse.de SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-21 15:14 ` Jörg Rödel @ 2023-03-21 17:48 ` Dr. David Alan Gilbert 2023-03-21 18:50 ` Jörg Rödel 2023-03-21 20:05 ` James Bottomley 1 sibling, 1 reply; 42+ messages in thread From: Dr. David Alan Gilbert @ 2023-03-21 17:48 UTC (permalink / raw) To: Jörg Rödel; +Cc: James Bottomley, amd-sev-snp, linux-coco, kvm * Jörg Rödel (jroedel@suse.de) wrote: > On Tue, Mar 21, 2023 at 09:43:48AM -0400, James Bottomley wrote: > > Could you describe these incompatible goals and explain why you think > > they are incompatible (as in why you and AMD don't think you can agree > > on it)? That would help the rest of us understand where the two SVSM > > implementations fit in our ongoing plans. > > The goal of COCONUT is to have an SVSM which has isolation capabilities > within itself. It already has percpu page-tables and in the end it will > be able to run services (like the TPM) as separate processes in ring 3 > using cooperative multitasking. > > With the current linux-svsm code-base this is difficult to achieve due > to its reliance on the x86-64 crate. For supporting a user-space like > execution mode the crate has too many limitations, mainly in its > page-table and IDT implementations. > > The IDT code from that crate, which is also used in linux-svsm, relies > on compiler-generated entry-code. This is not enough to support a > ring-3 execution mode with syscalls and several (possibly nested) IST > vectors. The next problem with the IDT code is that it doesn't allow > modification of return register state. This makes it impossible to > implement exception fixups to guard RMPADJUST instructions and VMPL1 > memory accesses in general. I'm curious why you're doing isolation using ring-3 stuff rather than another VMPL level? Dave > When we looked at the crate, the page-table implementation supported > basically a direct and an offset mapping, which will get us into > problems when support for non-contiguous mappings or sharing parts of a > page-table with another page-table is needed. So in the very beginning > of the project I decided to go with my own page-table implementation. > > Of course we could start changing linux-svsm to support the same goals, > but I think the end result will not be very different from what COCONUT > looks now. > > Regards, > > -- > Jörg Rödel > jroedel@suse.de > > SUSE Software Solutions Germany GmbH > Frankenstraße 146 > 90461 Nürnberg > Germany > > (HRB 36809, AG Nürnberg) > Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-21 17:48 ` Dr. David Alan Gilbert @ 2023-03-21 18:50 ` Jörg Rödel 0 siblings, 0 replies; 42+ messages in thread From: Jörg Rödel @ 2023-03-21 18:50 UTC (permalink / raw) To: Dr. David Alan Gilbert; +Cc: James Bottomley, amd-sev-snp, linux-coco, kvm On Tue, Mar 21, 2023 at 05:48:38PM +0000, Dr. David Alan Gilbert wrote: > I'm curious why you're doing isolation using ring-3 stuff rather than > another VMPL level? Two reasons: 1) CPL switch is much cheaper than VMPL switch 2) CPLs allow to isolate different services within the same VMPL. Having services run at, say, VMPL1 on CPL-0 will allow all services on VMPL1 to access each others memory. Regards, -- Jörg Rödel jroedel@suse.de SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-21 15:14 ` Jörg Rödel 2023-03-21 17:48 ` Dr. David Alan Gilbert @ 2023-03-21 20:05 ` James Bottomley 2023-03-22 1:29 ` Marc Orr 2023-03-22 9:15 ` Jörg Rödel 1 sibling, 2 replies; 42+ messages in thread From: James Bottomley @ 2023-03-21 20:05 UTC (permalink / raw) To: Jörg Rödel; +Cc: amd-sev-snp, linux-coco, kvm On Tue, 2023-03-21 at 16:14 +0100, Jörg Rödel wrote: > On Tue, Mar 21, 2023 at 09:43:48AM -0400, James Bottomley wrote: > > Could you describe these incompatible goals and explain why you > > think they are incompatible (as in why you and AMD don't think you > > can agree on it)? That would help the rest of us understand where > > the two SVSM implementations fit in our ongoing plans. > > The goal of COCONUT is to have an SVSM which has isolation > capabilities within itself. It already has percpu page-tables and in > the end it will be able to run services (like the TPM) as separate > processes in ring 3 using cooperative multitasking. > > With the current linux-svsm code-base this is difficult to achieve > due to its reliance on the x86-64 crate. For supporting a user-space > like execution mode the crate has too many limitations, mainly in its > page-table and IDT implementations. > > The IDT code from that crate, which is also used in linux-svsm, > relies on compiler-generated entry-code. This is not enough to > support a ring-3 execution mode with syscalls and several (possibly > nested) IST vectors. The next problem with the IDT code is that it > doesn't allow modification of return register state. This makes it > impossible to implement exception fixups to guard RMPADJUST > instructions and VMPL1 memory accesses in general. > > When we looked at the crate, the page-table implementation supported > basically a direct and an offset mapping, which will get us into > problems when support for non-contiguous mappings or sharing parts of > a page-table with another page-table is needed. So in the very > beginning of the project I decided to go with my own page-table > implementation. OK, so this doesn't sound like a problem with the AMD svsm, it sounds like a (solvable) issue with a particular crate in embedded rust. I have to say that embedded rust is so new, it's really hard to tell if this is just because it was developed by someone who didn't think of all the OS implications or because it's a fundamental issue within the rust ecosystem. Have you tried improving this crate? ... and also it's a nuisance we came to with our insistence on using rust; it certainly wouldn't have been an issue in C. I suspect improving the crate would help everyone (although I note the linux kernel isn't yet using this crate either). > Of course we could start changing linux-svsm to support the same > goals, but I think the end result will not be very different from > what COCONUT looks now. That's entirely possible, so what are the chances of combining the projects now so we don't get a split in community effort? James ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-21 20:05 ` James Bottomley @ 2023-03-22 1:29 ` Marc Orr 2023-03-22 17:57 ` Daniel P. Berrangé 2023-03-22 9:15 ` Jörg Rödel 1 sibling, 1 reply; 42+ messages in thread From: Marc Orr @ 2023-03-22 1:29 UTC (permalink / raw) To: jejb; +Cc: Jörg Rödel, amd-sev-snp, linux-coco, kvm On Tue, Mar 21, 2023 at 1:05 PM James Bottomley <jejb@linux.ibm.com> wrote: > > > Of course we could start changing linux-svsm to support the same > > goals, but I think the end result will not be very different from > > what COCONUT looks now. > > That's entirely possible, so what are the chances of combining the > projects now so we don't get a split in community effort? Very cool to see this announcement and read the discussion! One SVSM will be better for Google too. Specifically: - One hypervisor/SVSM startup sequence is easier for us to get working - One SVSM is easier to test/qualify/deploy - Generally speaking, things will be easier for us if all SNP VMs start running off of the same "first mutable code". I.e., the same SVSM, UEFI, etc. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-22 1:29 ` Marc Orr @ 2023-03-22 17:57 ` Daniel P. Berrangé 0 siblings, 0 replies; 42+ messages in thread From: Daniel P. Berrangé @ 2023-03-22 17:57 UTC (permalink / raw) To: Marc Orr; +Cc: jejb, Jörg Rödel, amd-sev-snp, linux-coco, kvm On Tue, Mar 21, 2023 at 06:29:29PM -0700, Marc Orr wrote: > On Tue, Mar 21, 2023 at 1:05 PM James Bottomley <jejb@linux.ibm.com> wrote: > > > > > Of course we could start changing linux-svsm to support the same > > > goals, but I think the end result will not be very different from > > > what COCONUT looks now. > > > > That's entirely possible, so what are the chances of combining the > > projects now so we don't get a split in community effort? > > Very cool to see this announcement and read the discussion! > > One SVSM will be better for Google too. Specifically: > - One hypervisor/SVSM startup sequence is easier for us to get working > - One SVSM is easier to test/qualify/deploy > - Generally speaking, things will be easier for us if all SNP VMs > start running off of the same "first mutable code". I.e., the same > SVSM, UEFI, etc. I agree with this from the Red Hat side. We would prefer there to be a standard / common SVSM used by all [OSS] hypervisors/clouds, to reduce permutations that guest OS vendors/tenants have to develop/test/deploy against. It looks like even developing one high quality feature rich SVSM is a non-trivial undertaking, so I agree with James that it is undesirable to divide community resources across many competing impls, without a compelling justification. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-21 20:05 ` James Bottomley 2023-03-22 1:29 ` Marc Orr @ 2023-03-22 9:15 ` Jörg Rödel 2023-03-22 18:07 ` Daniel P. Berrangé 1 sibling, 1 reply; 42+ messages in thread From: Jörg Rödel @ 2023-03-22 9:15 UTC (permalink / raw) To: James Bottomley; +Cc: amd-sev-snp, linux-coco, kvm On Tue, Mar 21, 2023 at 04:05:35PM -0400, James Bottomley wrote: > OK, so this doesn't sound like a problem with the AMD svsm, it sounds > like a (solvable) issue with a particular crate in embedded rust. I > have to say that embedded rust is so new, it's really hard to tell if > this is just because it was developed by someone who didn't think of > all the OS implications or because it's a fundamental issue within the > rust ecosystem. Have you tried improving this crate? ... and also it's > a nuisance we came to with our insistence on using rust; it certainly > wouldn't have been an issue in C. I suspect improving the crate would > help everyone (although I note the linux kernel isn't yet using this > crate either). We did not consider to work on the x86-64 crate for now, that would open a new can of worms and would have delayed the project even further. I agree that the crate would benefit from that, but targeting questions like how to introduce new functionality while keeping it compatible to other users is a project on its own. COCONUT is now in a state where it has its own page-table and IDT/entry code implementations which fit its needs and can be quickly adapted as we move forward. When the dust settles we can re-visit that question and start contributing back to this crate and possibly adopt it. There is actually one thing from the crate I would like to have in COCONUT too, which is the abstraction for VirtAddr and PhysAddr. COCONUT just defines those as usize, which is rather limited and leads to ugly code here and there. > That's entirely possible, so what are the chances of combining the > projects now so we don't get a split in community effort? That is not on us to decide. I agree that a single effort is much better, but at the same time I don't think that porting upstream code between both implementations is worthwile (things are different with the work that is currently happening on-top of linux-svsm). From a functionality pov both projects are mostly on par in their upstream branches. COCONUT is lacking one piece or another, like it does not work around the VMSA@2M-aligned erratum yet. On the other hand COCONUT has a bigger code-base, implementing exception fixups and bracktraces already. Soon COCONUT will gain an ELF parser (and building on that ASLR) to load the SVSM kernel as an ELF file from the stage2 loader. The ELF parser is needed anyway for ring-3 support, other changes are also under development. There is of course work building on linux-svsm out there, too. It would be interesting to get an overview of that. We are already looking into porting over the attestation code IBM wrote for linux-svsm (although we would prefer IBM submitting it :) ). The vTPM code out there can not be ported over as-is, as COCONUT will not link a whole TPM library in its code-base. But maybe it can be the base for a separate vTPM binary run by COCONUT. In general, since both projects are written in Rust and the APIs are small, it is not a big effort to port over changes for linux-svsm to COCONUT. Regards, -- Jörg Rödel jroedel@suse.de SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-22 9:15 ` Jörg Rödel @ 2023-03-22 18:07 ` Daniel P. Berrangé 2023-03-22 18:24 ` Dionna Amalie Glaze 0 siblings, 1 reply; 42+ messages in thread From: Daniel P. Berrangé @ 2023-03-22 18:07 UTC (permalink / raw) To: Jörg Rödel; +Cc: James Bottomley, amd-sev-snp, linux-coco, kvm On Wed, Mar 22, 2023 at 10:15:33AM +0100, Jörg Rödel wrote: > There is of course work building on linux-svsm out there, too. It would > be interesting to get an overview of that. We are already looking into > porting over the attestation code IBM wrote for linux-svsm (although we > would prefer IBM submitting it :) ). The vTPM code out there can not be > ported over as-is, as COCONUT will not link a whole TPM library in its > code-base. But maybe it can be the base for a separate vTPM binary run > by COCONUT. For whichever SVSM impl becomes the dominant, the vTPM support with persistence, is something I see as a critical component. It lets the guest OS boot process at least be largely decoupled from the CVM attestation process, and instead rely on the pre-existing support for TPMs, SecureBoot & secret sealing which is common to bare metal and non-confidential VM deployments alike. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-22 18:07 ` Daniel P. Berrangé @ 2023-03-22 18:24 ` Dionna Amalie Glaze 0 siblings, 0 replies; 42+ messages in thread From: Dionna Amalie Glaze @ 2023-03-22 18:24 UTC (permalink / raw) To: Daniel P. Berrangé Cc: Jörg Rödel, linux-coco, kvm, amd-sev-snp On Wed, Mar 22, 2023 at 11:08 AM Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Wed, Mar 22, 2023 at 10:15:33AM +0100, Jörg Rödel wrote: > > There is of course work building on linux-svsm out there, too. It would > > be interesting to get an overview of that. We are already looking into > > porting over the attestation code IBM wrote for linux-svsm (although we > > would prefer IBM submitting it :) ). The vTPM code out there can not be > > ported over as-is, as COCONUT will not link a whole TPM library in its > > code-base. But maybe it can be the base for a separate vTPM binary run > > by COCONUT. > > For whichever SVSM impl becomes the dominant, the vTPM support with > persistence, is something I see as a critical component. It lets the > guest OS boot process at least be largely decoupled from the CVM > attestation process, and instead rely on the pre-existing support for > TPMs, SecureBoot & secret sealing which is common to bare metal and > non-confidential VM deployments alike. > NVDATA in a confidential setting in my mind needs a whole an attested sealing key escrow service to really remove the host from the trust boundary. Ideally the service never goes down and can have an unbroken chain of custody back to the original ingestion into the service. If the service ever has all machines go down, it would have to have another trusted service of rollback-safe files. That depends on trusted time. The service nodes plays hot potato with key replication and has logged and attested cluster management operations: * sealing secrets forward to a new version that was signed by a pre-registered trusted operator. * adding more machines to a cluster that has access to the secrets by a trusted operator. * the sealing enclaves themselves need a secure source of time to know when the enclave came up and whether it got its secrets from a rollback-safe sealed-to-code file or will depend on gossip. Trusted persistence really means there's some trusted workload that never goes down that is able to take a sealing key bound to an expected workload measurement and return a secret that will only be unsealed when the vTPM gets to the bound measurement. It's a fun problem, one I've been wanting to work on, but yeah there's a bunch of other more pressing work to do first. > With regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| > -- -Dionna Glaze, PhD (she/her) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-21 9:29 [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP Jörg Rödel 2023-03-21 11:09 ` James Bottomley @ 2023-03-21 15:06 ` Dr. David Alan Gilbert 2023-03-21 15:25 ` Jörg Rödel 2023-04-11 19:57 ` Tom Lendacky 2023-05-02 23:03 ` Tom Lendacky 3 siblings, 1 reply; 42+ messages in thread From: Dr. David Alan Gilbert @ 2023-03-21 15:06 UTC (permalink / raw) To: Jörg Rödel; +Cc: amd-sev-snp, linux-coco, kvm * Jörg Rödel (jroedel@suse.de) wrote: > Hi, > > We are happy to announce that last week our secure VM service module > (SVSM) went public on GitHub for everyone to try it out and participate > in its further development. It is dual-licensed under the MIT and > APACHE-2.0 licenses. > > The project is written in Rust and can be cloned from: > > https://github.com/coconut-svsm/svsm > > There are also repositories in the github project with the Linux host and > guest, EDK2 and QEMU changes needed to run the SVSM and boot up a full > Linux guest. > > The SVSM repository contains an installation guide in the INSTALL.md > file and contributor hints in CONTRIBUTING.md. > > A blog entry with more details is here: > > https://www.suse.com/c/suse-open-sources-secure-vm-service-module-for-confidential-computing/ > > We also thank AMD for implementing and providing the necessary changes > to Linux and EDK2 to make an SVSM possible. Interesting; it would have been nice to have known about this a little earlier, some people have been working on stuff built on top of the AMD one for a while. You mention two things that I wonder how they interact: a) TPMs in the future at a higher ring b) Making (almost) unmodified guests What interface do you expect the guest to see from the TPM - would it look like an existing TPM hardware interface or would you need some changes? Dave > Have a lot of fun! > > -- > Jörg Rödel > jroedel@suse.de > > SUSE Software Solutions Germany GmbH > Frankenstraße 146 > 90461 Nürnberg > Germany > > (HRB 36809, AG Nürnberg) > Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-21 15:06 ` Dr. David Alan Gilbert @ 2023-03-21 15:25 ` Jörg Rödel 2023-03-21 16:56 ` Dr. David Alan Gilbert 0 siblings, 1 reply; 42+ messages in thread From: Jörg Rödel @ 2023-03-21 15:25 UTC (permalink / raw) To: Dr. David Alan Gilbert; +Cc: amd-sev-snp, linux-coco, kvm Hi Dave, On Tue, Mar 21, 2023 at 03:06:19PM +0000, Dr. David Alan Gilbert wrote: > Interesting; it would have been nice to have known about this a little > earlier, some people have been working on stuff built on top of the AMD > one for a while. Sorry for that, we wanted to have it in a state where it could at least boot an SMP Linux guest. It took us some more time to get the foundations right and get to that point. > You mention two things that I wonder how they interact: > > a) TPMs in the future at a higher ring > b) Making (almost) unmodified guests > > What interface do you expect the guest to see from the TPM - would it > look like an existing TPM hardware interface or would you need some > changes? For a) without b) the guest interface will be the SVSM TPM protocol. The ring-0 code will forward any request to the TPM process and return to the guest when it is done. For b), or the paravisor mode, this is the vision, which is probably more than a year out. The idea behind that is to be able to emulate what Hyper-V is doing to boot Windows guests under SEV-SNP on an open source SW stack. How the TPM interface will look like for that paravisor mode is not clear yet. In theory we can emulate a real TPM interface to make this work, but that is not sure yet. Regards, -- Jörg Rödel jroedel@suse.de SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-21 15:25 ` Jörg Rödel @ 2023-03-21 16:56 ` Dr. David Alan Gilbert 2023-03-21 19:03 ` Jörg Rödel 0 siblings, 1 reply; 42+ messages in thread From: Dr. David Alan Gilbert @ 2023-03-21 16:56 UTC (permalink / raw) To: Jörg Rödel; +Cc: amd-sev-snp, linux-coco, kvm * Jörg Rödel (jroedel@suse.de) wrote: > Hi Dave, > > On Tue, Mar 21, 2023 at 03:06:19PM +0000, Dr. David Alan Gilbert wrote: > > Interesting; it would have been nice to have known about this a little > > earlier, some people have been working on stuff built on top of the AMD > > one for a while. > > Sorry for that, we wanted to have it in a state where it could at least > boot an SMP Linux guest. It took us some more time to get the > foundations right and get to that point. > > > You mention two things that I wonder how they interact: > > > > a) TPMs in the future at a higher ring > > b) Making (almost) unmodified guests > > > > What interface do you expect the guest to see from the TPM - would it > > look like an existing TPM hardware interface or would you need some > > changes? > > For a) without b) the guest interface will be the SVSM TPM protocol. The > ring-0 code will forward any request to the TPM process and return to > the guest when it is done. > > For b), or the paravisor mode, this is the vision, which is probably > more than a year out. The idea behind that is to be able to emulate what > Hyper-V is doing to boot Windows guests under SEV-SNP on an open source > SW stack. > > How the TPM interface will look like for that paravisor mode is not > clear yet. In theory we can emulate a real TPM interface to make this > work, but that is not sure yet. OK, I'm just trying to avoid having guests that have a zillion different TPM setups for different SVSM and clouds. Timing is a little tricky here; in many ways the thing that sounds nicest to me about Coconut is the mostly-unmodified guest (b) - but if that's a while out then hmm. Dave > Regards, > > -- > Jörg Rödel > jroedel@suse.de > > SUSE Software Solutions Germany GmbH > Frankenstraße 146 > 90461 Nürnberg > Germany > > (HRB 36809, AG Nürnberg) > Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-21 16:56 ` Dr. David Alan Gilbert @ 2023-03-21 19:03 ` Jörg Rödel 2023-03-21 19:53 ` Dr. David Alan Gilbert 0 siblings, 1 reply; 42+ messages in thread From: Jörg Rödel @ 2023-03-21 19:03 UTC (permalink / raw) To: Dr. David Alan Gilbert; +Cc: amd-sev-snp, linux-coco, kvm On Tue, Mar 21, 2023 at 04:56:20PM +0000, Dr. David Alan Gilbert wrote: > OK, I'm just trying to avoid having guests that have a zillion different > TPM setups for different SVSM and clouds. My guess it that it will either be the SVSM TPM protocol or an emulation of an existing TPM interface. > Timing is a little tricky here; in many ways the thing that sounds > nicest to me about Coconut is the mostly-unmodified guest (b) - but if > that's a while out then hmm. Yeah, would be nice. But we are still in the early stages of SVSM development, so the priority now is to get services up and running. But the project is open source and anyone can start looking into the unmodified guest handling and send PRs. Making this happen is certainly a multi-step process, as it requires several things to be implemented. Just out of my head an incomplete list what is required: 1) ReflectVC handling with instruction decoder and guest TLB flush awareness 2) vTOM handling 3) Interrupt proxying using alternate injection (that can make sense even earlier and without the other features imho) So its quite some work, but if someone wants to look into that now I am all for it. Regards, -- Jörg Rödel jroedel@suse.de SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-21 19:03 ` Jörg Rödel @ 2023-03-21 19:53 ` Dr. David Alan Gilbert 2023-03-22 9:19 ` Jörg Rödel 0 siblings, 1 reply; 42+ messages in thread From: Dr. David Alan Gilbert @ 2023-03-21 19:53 UTC (permalink / raw) To: Jörg Rödel; +Cc: amd-sev-snp, linux-coco, kvm * Jörg Rödel (jroedel@suse.de) wrote: > On Tue, Mar 21, 2023 at 04:56:20PM +0000, Dr. David Alan Gilbert wrote: > > OK, I'm just trying to avoid having guests that have a zillion different > > TPM setups for different SVSM and clouds. > > My guess it that it will either be the SVSM TPM protocol or an emulation > of an existing TPM interface. OK; the other thing that needs to get nailed down for the vTPM's is the relationship between the vTPM attestation and the SEV attestation. i.e. how to prove that the vTPM you're dealing with is from an SNP host. (Azure have a hack of putting an SNP attestation report into the vTPM NVRAM; see https://github.com/Azure/confidential-computing-cvm-guest-attestation/blob/main/cvm-guest-attestation.md ) > > Timing is a little tricky here; in many ways the thing that sounds > > nicest to me about Coconut is the mostly-unmodified guest (b) - but if > > that's a while out then hmm. > > Yeah, would be nice. But we are still in the early stages of SVSM > development, so the priority now is to get services up and running. > > But the project is open source and anyone can start looking into the > unmodified guest handling and send PRs. Making this happen is certainly > a multi-step process, as it requires several things to be implemented. > Just out of my head an incomplete list what is required: > > 1) ReflectVC handling with instruction decoder and guest TLB > flush awareness > 2) vTOM handling > 3) Interrupt proxying using alternate injection (that can make > sense even earlier and without the other features imho) So all the easy stuff then :-) > So its quite some work, but if someone wants to look into that now I am > all for it. Dave > > Regards, > > -- > Jörg Rödel > jroedel@suse.de > > SUSE Software Solutions Germany GmbH > Frankenstraße 146 > 90461 Nürnberg > Germany > > (HRB 36809, AG Nürnberg) > Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-21 19:53 ` Dr. David Alan Gilbert @ 2023-03-22 9:19 ` Jörg Rödel 2023-03-22 9:43 ` Alexander Graf 0 siblings, 1 reply; 42+ messages in thread From: Jörg Rödel @ 2023-03-22 9:19 UTC (permalink / raw) To: Dr. David Alan Gilbert; +Cc: amd-sev-snp, linux-coco, kvm On Tue, Mar 21, 2023 at 07:53:58PM +0000, Dr. David Alan Gilbert wrote: > OK; the other thing that needs to get nailed down for the vTPM's is the > relationship between the vTPM attestation and the SEV attestation. > i.e. how to prove that the vTPM you're dealing with is from an SNP host. > (Azure have a hack of putting an SNP attestation report into the vTPM > NVRAM; see > https://github.com/Azure/confidential-computing-cvm-guest-attestation/blob/main/cvm-guest-attestation.md > ) When using the SVSM TPM protocol it should be proven already that the vTPM is part of the SNP trusted base, no? The TPM communication is implicitly encrypted by the VMs memory key and the SEV attestation report proves that the correct vTPM is executing. Regards, -- Jörg Rödel jroedel@suse.de SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-22 9:19 ` Jörg Rödel @ 2023-03-22 9:43 ` Alexander Graf 2023-03-22 10:34 ` Dr. David Alan Gilbert 0 siblings, 1 reply; 42+ messages in thread From: Alexander Graf @ 2023-03-22 9:43 UTC (permalink / raw) To: Jörg Rödel, Dr. David Alan Gilbert; +Cc: amd-sev-snp, linux-coco, kvm Hi Jörg, On 22.03.23 10:19, Jörg Rödel wrote: > On Tue, Mar 21, 2023 at 07:53:58PM +0000, Dr. David Alan Gilbert wrote: >> OK; the other thing that needs to get nailed down for the vTPM's is the >> relationship between the vTPM attestation and the SEV attestation. >> i.e. how to prove that the vTPM you're dealing with is from an SNP host. >> (Azure have a hack of putting an SNP attestation report into the vTPM >> NVRAM; see >> https://github.com/Azure/confidential-computing-cvm-guest-attestation/blob/main/cvm-guest-attestation.md >> ) > When using the SVSM TPM protocol it should be proven already that the > vTPM is part of the SNP trusted base, no? The TPM communication is > implicitly encrypted by the VMs memory key and the SEV attestation > report proves that the correct vTPM is executing. What you want to achieve eventually is to take a report from the vTPM and submit only that to an external authorization entity that looks at it and says "Yup, you ran in SEV-SNP, I trust your TCB, I trust your TPM implementation, I also trust your PCR values" and based on that provides access to whatever resource you want to access. To do that, you need to link SEV-SNP and TPM measurements/reports together. And the easiest way to do that is by providing the SEV-SNP report as part of the TPM: You can then use the hash of the SEV-SNP report as signing key for example. I think the key here is that you need to propagate that link to an external party, not (only) to the VM. Alex Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-22 9:43 ` Alexander Graf @ 2023-03-22 10:34 ` Dr. David Alan Gilbert 2023-03-22 17:37 ` Dionna Amalie Glaze 0 siblings, 1 reply; 42+ messages in thread From: Dr. David Alan Gilbert @ 2023-03-22 10:34 UTC (permalink / raw) To: Alexander Graf; +Cc: Jörg Rödel, amd-sev-snp, linux-coco, kvm * Alexander Graf (graf@amazon.com) wrote: > Hi Jörg, > > On 22.03.23 10:19, Jörg Rödel wrote: > > > On Tue, Mar 21, 2023 at 07:53:58PM +0000, Dr. David Alan Gilbert wrote: > > > OK; the other thing that needs to get nailed down for the vTPM's is the > > > relationship between the vTPM attestation and the SEV attestation. > > > i.e. how to prove that the vTPM you're dealing with is from an SNP host. > > > (Azure have a hack of putting an SNP attestation report into the vTPM > > > NVRAM; see > > > https://github.com/Azure/confidential-computing-cvm-guest-attestation/blob/main/cvm-guest-attestation.md > > > ) > > When using the SVSM TPM protocol it should be proven already that the > > vTPM is part of the SNP trusted base, no? The TPM communication is > > implicitly encrypted by the VMs memory key and the SEV attestation > > report proves that the correct vTPM is executing. > > > What you want to achieve eventually is to take a report from the vTPM and > submit only that to an external authorization entity that looks at it and > says "Yup, you ran in SEV-SNP, I trust your TCB, I trust your TPM > implementation, I also trust your PCR values" and based on that provides > access to whatever resource you want to access. > > To do that, you need to link SEV-SNP and TPM measurements/reports together. > And the easiest way to do that is by providing the SEV-SNP report as part of > the TPM: You can then use the hash of the SEV-SNP report as signing key for > example. Yeh; I think the SVSM TPM protocol has some proof of that as well; the SVSM spec lists 'SVSM_ATTEST_SINGLE_SERVICE Manifest Data' that contains 'TPMT_PUBLIC structure of the endorsement key'. So I *think* that's saying that the SEV attestation report contains something from the EK of the vTPM. > I think the key here is that you need to propagate that link to an external > party, not (only) to the VM. Yeh. Dave > > > Alex > > > > > > Amazon Development Center Germany GmbH > Krausenstr. 38 > 10117 Berlin > Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss > Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B > Sitz: Berlin > Ust-ID: DE 289 237 879 > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-22 10:34 ` Dr. David Alan Gilbert @ 2023-03-22 17:37 ` Dionna Amalie Glaze 2023-03-22 17:47 ` Dr. David Alan Gilbert 0 siblings, 1 reply; 42+ messages in thread From: Dionna Amalie Glaze @ 2023-03-22 17:37 UTC (permalink / raw) To: Dr. David Alan Gilbert Cc: Alexander Graf, Jörg Rödel, amd-sev-snp, linux-coco, kvm On Wed, Mar 22, 2023 at 3:34 AM Dr. David Alan Gilbert <dgilbert@redhat.com> wrote: > > * Alexander Graf (graf@amazon.com) wrote: > > Hi Jörg, > > > > On 22.03.23 10:19, Jörg Rödel wrote: > > > > > On Tue, Mar 21, 2023 at 07:53:58PM +0000, Dr. David Alan Gilbert wrote: > > > > OK; the other thing that needs to get nailed down for the vTPM's is the > > > > relationship between the vTPM attestation and the SEV attestation. > > > > i.e. how to prove that the vTPM you're dealing with is from an SNP host. > > > > (Azure have a hack of putting an SNP attestation report into the vTPM > > > > NVRAM; see > > > > https://github.com/Azure/confidential-computing-cvm-guest-attestation/blob/main/cvm-guest-attestation.md > > > > ) > > > When using the SVSM TPM protocol it should be proven already that the > > > vTPM is part of the SNP trusted base, no? The TPM communication is > > > implicitly encrypted by the VMs memory key and the SEV attestation > > > report proves that the correct vTPM is executing. > > > > > > What you want to achieve eventually is to take a report from the vTPM and > > submit only that to an external authorization entity that looks at it and > > says "Yup, you ran in SEV-SNP, I trust your TCB, I trust your TPM > > implementation, I also trust your PCR values" and based on that provides > > access to whatever resource you want to access. > > > > To do that, you need to link SEV-SNP and TPM measurements/reports together. > > And the easiest way to do that is by providing the SEV-SNP report as part of > > the TPM: You can then use the hash of the SEV-SNP report as signing key for > > example. > > Yeh; I think the SVSM TPM protocol has some proof of that as well; the > SVSM spec lists 'SVSM_ATTEST_SINGLE_SERVICE Manifest Data' that contains > 'TPMT_PUBLIC structure of the endorsement key'. > So I *think* that's saying that the SEV attestation report contains > something from the EK of the vTPM. > > > I think the key here is that you need to propagate that link to an external > > party, not (only) to the VM. > > Yeh. > Excuse my perhaps naivete, but would it not be in the TCG's wheelhouse to specify how a TPM's firmware (SVSM) / bootloader (SEV-SNP) should be attested? The EK as well? I think this might need to jump back to the vTPM protocol thread since this is about COCONUT, but I'm worried we're talking about AMD-specific long-term formats when perhaps the trusted computing group should be widening its scope to how a TPM should be virtualized. I appreciate that we're attempting to solve the problem in the short term, and certainly the SVSM will need attestation capabilities, but the linking to the TPM is dicey without that conversation with TCG, IMHO. > Dave > > > > > > Alex > > > > > > > > > > > > Amazon Development Center Germany GmbH > > Krausenstr. 38 > > 10117 Berlin > > Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss > > Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B > > Sitz: Berlin > > Ust-ID: DE 289 237 879 > > > > > -- > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK > > -- -Dionna Glaze, PhD (she/her) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-22 17:37 ` Dionna Amalie Glaze @ 2023-03-22 17:47 ` Dr. David Alan Gilbert 2023-03-22 21:53 ` James Bottomley 0 siblings, 1 reply; 42+ messages in thread From: Dr. David Alan Gilbert @ 2023-03-22 17:47 UTC (permalink / raw) To: Dionna Amalie Glaze Cc: Alexander Graf, Jörg Rödel, amd-sev-snp, linux-coco, kvm * Dionna Amalie Glaze (dionnaglaze@google.com) wrote: > On Wed, Mar 22, 2023 at 3:34 AM Dr. David Alan Gilbert > <dgilbert@redhat.com> wrote: > > > > * Alexander Graf (graf@amazon.com) wrote: > > > Hi Jörg, > > > > > > On 22.03.23 10:19, Jörg Rödel wrote: > > > > > > > On Tue, Mar 21, 2023 at 07:53:58PM +0000, Dr. David Alan Gilbert wrote: > > > > > OK; the other thing that needs to get nailed down for the vTPM's is the > > > > > relationship between the vTPM attestation and the SEV attestation. > > > > > i.e. how to prove that the vTPM you're dealing with is from an SNP host. > > > > > (Azure have a hack of putting an SNP attestation report into the vTPM > > > > > NVRAM; see > > > > > https://github.com/Azure/confidential-computing-cvm-guest-attestation/blob/main/cvm-guest-attestation.md > > > > > ) > > > > When using the SVSM TPM protocol it should be proven already that the > > > > vTPM is part of the SNP trusted base, no? The TPM communication is > > > > implicitly encrypted by the VMs memory key and the SEV attestation > > > > report proves that the correct vTPM is executing. > > > > > > > > > What you want to achieve eventually is to take a report from the vTPM and > > > submit only that to an external authorization entity that looks at it and > > > says "Yup, you ran in SEV-SNP, I trust your TCB, I trust your TPM > > > implementation, I also trust your PCR values" and based on that provides > > > access to whatever resource you want to access. > > > > > > To do that, you need to link SEV-SNP and TPM measurements/reports together. > > > And the easiest way to do that is by providing the SEV-SNP report as part of > > > the TPM: You can then use the hash of the SEV-SNP report as signing key for > > > example. > > > > Yeh; I think the SVSM TPM protocol has some proof of that as well; the > > SVSM spec lists 'SVSM_ATTEST_SINGLE_SERVICE Manifest Data' that contains > > 'TPMT_PUBLIC structure of the endorsement key'. > > So I *think* that's saying that the SEV attestation report contains > > something from the EK of the vTPM. > > > > > I think the key here is that you need to propagate that link to an external > > > party, not (only) to the VM. > > > > Yeh. > > > > Excuse my perhaps naivete, but would it not be in the TCG's wheelhouse > to specify how a TPM's firmware (SVSM) / bootloader (SEV-SNP) should > be attested? The EK as well? > > I think this might need to jump back to the vTPM protocol thread since > this is about COCONUT, but I'm worried we're talking about > AMD-specific long-term formats when perhaps the trusted computing > group should be widening its scope to how a TPM should be virtualized. > I appreciate that we're attempting to solve the problem in the short > term, and certainly the SVSM will need attestation capabilities, but > the linking to the TPM is dicey without that conversation with TCG, > IMHO. Some standardisation of the link between the vTPM and the underlying CoCo hardware would be great; there's at least 2 or 3 CoCo linked vTPMs already and I don't think they're sharing any idea of that. Whether it's TCG I'm not sure; It doesn't seem to me to make sense for them to specify the flow to bring the vTPM up or the details of the underlying CoCo's attestation; but standardising how the two processes are tied together might be possible. Dave > > Dave > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > Amazon Development Center Germany GmbH > > > Krausenstr. 38 > > > 10117 Berlin > > > Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss > > > Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B > > > Sitz: Berlin > > > Ust-ID: DE 289 237 879 > > > > > > > > -- > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK > > > > > > > -- > -Dionna Glaze, PhD (she/her) > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-22 17:47 ` Dr. David Alan Gilbert @ 2023-03-22 21:53 ` James Bottomley 0 siblings, 0 replies; 42+ messages in thread From: James Bottomley @ 2023-03-22 21:53 UTC (permalink / raw) To: Dr. David Alan Gilbert, Dionna Amalie Glaze; +Cc: linux-coco, kvm, amd-sev-snp On Wed, 2023-03-22 at 17:47 +0000, Dr. David Alan Gilbert wrote: [...] > > I think this might need to jump back to the vTPM protocol thread > > since this is about COCONUT, but I'm worried we're talking about > > AMD-specific long-term formats when perhaps the trusted computing > > group should be widening its scope to how a TPM should be > > virtualized. I appreciate that we're attempting to solve the > > problem in the short term, and certainly the SVSM will need > > attestation capabilities, but the linking to the TPM is dicey > > without that conversation with TCG, IMHO. > > Some standardisation of the link between the vTPM and the underlying > CoCo hardware would be great; there's at least 2 or 3 CoCo linked > vTPMs already and I don't think they're sharing any idea of that. Well, for SNP, it's easy: the VMPL0 labelled attestation report proves the SVSM and other components including OVMF and vTPM code implementation. We insert a hash of the manufactured EK into the report and that gives proof from the trusted SVSM of the EK belonging to the vTPM (essentially binding the vTPM to the VM). The same thing would work for other CoCo VM environments. If we do ephemeral vTPMs, the binding is one time and there's no persistent state security issue, so the SVSM-vTPM attestation is all you need to begin trusting the vTPM measurements. > Whether it's TCG I'm not sure; It doesn't seem to me to make sense > for them to specify the flow to bring the vTPM up or the details of > the underlying CoCo's attestation; but standardising how the two > processes are tied together might be possible. I think the TCG is probably not going to touch that because how you attest the code that will run as the SVSM and vTPM is very specific to each CoCo implementation. However, they all provide a user data like field which allows you to add information from the to be verified as trusted SVSM, so you can use it for the EK, which is pretty identical to the above proposal. James ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-21 9:29 [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP Jörg Rödel 2023-03-21 11:09 ` James Bottomley 2023-03-21 15:06 ` Dr. David Alan Gilbert @ 2023-04-11 19:57 ` Tom Lendacky 2023-04-11 20:01 ` Dionna Amalie Glaze 2023-04-13 16:57 ` James Bottomley 2023-05-02 23:03 ` Tom Lendacky 3 siblings, 2 replies; 42+ messages in thread From: Tom Lendacky @ 2023-04-11 19:57 UTC (permalink / raw) To: Jörg Rödel, amd-sev-snp, linux-coco, kvm On 3/21/23 04:29, Jörg Rödel wrote: > Hi, > > We are happy to announce that last week our secure VM service module > (SVSM) went public on GitHub for everyone to try it out and participate > in its further development. It is dual-licensed under the MIT and > APACHE-2.0 licenses. > > The project is written in Rust and can be cloned from: > > https://github.com/coconut-svsm/svsm > > There are also repositories in the github project with the Linux host and > guest, EDK2 and QEMU changes needed to run the SVSM and boot up a full > Linux guest. > > The SVSM repository contains an installation guide in the INSTALL.md > file and contributor hints in CONTRIBUTING.md. > > A blog entry with more details is here: > > https://www.suse.com/c/suse-open-sources-secure-vm-service-module-for-confidential-computing/ > > We also thank AMD for implementing and providing the necessary changes > to Linux and EDK2 to make an SVSM possible. Just wanted to let everyone know that I'm looking into what we can do to move towards a single SVSM project so that resources aren't split between the two. I was hoping to have a comparison, questions and observations between the two available by now, however, I'm behind on that... but, I am working on it. Thanks, Tom > > Have a lot of fun! > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-04-11 19:57 ` Tom Lendacky @ 2023-04-11 20:01 ` Dionna Amalie Glaze 2023-04-13 16:57 ` James Bottomley 1 sibling, 0 replies; 42+ messages in thread From: Dionna Amalie Glaze @ 2023-04-11 20:01 UTC (permalink / raw) To: Tom Lendacky; +Cc: Jörg Rödel, amd-sev-snp, linux-coco, kvm On Tue, Apr 11, 2023 at 12:57 PM Tom Lendacky <thomas.lendacky@amd.com> wrote: > > On 3/21/23 04:29, Jörg Rödel wrote: > > Hi, > > > > We are happy to announce that last week our secure VM service module > > (SVSM) went public on GitHub for everyone to try it out and participate > > in its further development. It is dual-licensed under the MIT and > > APACHE-2.0 licenses. > > > > The project is written in Rust and can be cloned from: > > > > https://github.com/coconut-svsm/svsm > > > > There are also repositories in the github project with the Linux host and > > guest, EDK2 and QEMU changes needed to run the SVSM and boot up a full > > Linux guest. > > > > The SVSM repository contains an installation guide in the INSTALL.md > > file and contributor hints in CONTRIBUTING.md. > > > > A blog entry with more details is here: > > > > https://www.suse.com/c/suse-open-sources-secure-vm-service-module-for-confidential-computing/ > > > > We also thank AMD for implementing and providing the necessary changes > > to Linux and EDK2 to make an SVSM possible. > > Just wanted to let everyone know that I'm looking into what we can do to > move towards a single SVSM project so that resources aren't split between > the two. > > I was hoping to have a comparison, questions and observations between the > two available by now, however, I'm behind on that... but, I am working on it. > This is a happy development. Glad to hear it and thanks for your work, Tom, Jörg, and all collaborators. > Thanks, > Tom > > > > > Have a lot of fun! > > -- -Dionna Glaze, PhD (she/her) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-04-11 19:57 ` Tom Lendacky 2023-04-11 20:01 ` Dionna Amalie Glaze @ 2023-04-13 16:57 ` James Bottomley 2023-04-14 9:00 ` Jörg Rödel 1 sibling, 1 reply; 42+ messages in thread From: James Bottomley @ 2023-04-13 16:57 UTC (permalink / raw) To: Tom Lendacky, Jörg Rödel, amd-sev-snp, linux-coco, kvm On Tue, 2023-04-11 at 14:57 -0500, Tom Lendacky wrote: > On 3/21/23 04:29, Jörg Rödel wrote: > > Hi, > > > > We are happy to announce that last week our secure VM service > > module (SVSM) went public on GitHub for everyone to try it out and > > participate in its further development. It is dual-licensed under > > the MIT and APACHE-2.0 licenses. > > > > The project is written in Rust and can be cloned from: > > > > https://github.com/coconut-svsm/svsm > > > > There are also repositories in the github project with the Linux > > host and guest, EDK2 and QEMU changes needed to run the SVSM and > > boot up a full Linux guest. > > > > The SVSM repository contains an installation guide in the > > INSTALL.md file and contributor hints in CONTRIBUTING.md. > > > > A blog entry with more details is here: > > > > https://www.suse.com/c/suse-open-sources-secure-vm-service- > > module-for-confidential-computing/ > > > > We also thank AMD for implementing and providing the necessary > > changes to Linux and EDK2 to make an SVSM possible. > > Just wanted to let everyone know that I'm looking into what we can do > to move towards a single SVSM project so that resources aren't split > between the two. > > I was hoping to have a comparison, questions and observations between > the two available by now, however, I'm behind on that... but, I am > working on it. We (IBM) did look at what it might take to add a vTPM to Coconut, but we ran into the problem that if we do it at CPL3 (which looks desirable), then we have to wait until pretty much every one of the twelve(!) tasks in this list is complete: https://github.com/coconut-svsm/svsm/issues/16 At a conservative estimate, it looks like completion of all twelve would take a team of people over a year to achieve. Some of these tasks, like task switching and a syscall interface, really don't look like they belong in a simple service module, like we were imagining an SVSM would operate, is there some rationale behind this (or ideally some architecture document that gives the justifications)? I think what I'm really asking is can we get to CPL3 separation way sooner than completion of all these tasks? Regards, James ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-04-13 16:57 ` James Bottomley @ 2023-04-14 9:00 ` Jörg Rödel 0 siblings, 0 replies; 42+ messages in thread From: Jörg Rödel @ 2023-04-14 9:00 UTC (permalink / raw) To: James Bottomley; +Cc: Tom Lendacky, amd-sev-snp, linux-coco, kvm Hi James, On Thu, Apr 13, 2023 at 12:57:38PM -0400, James Bottomley wrote: > We (IBM) did look at what it might take to add a vTPM to Coconut, but > we ran into the problem that if we do it at CPL3 (which looks > desirable), then we have to wait until pretty much every one of the > twelve(!) tasks in this list is complete: > > https://github.com/coconut-svsm/svsm/issues/16 Thanks for looking into the code-base. Our approach to getting CPL-3 support is incremental. We can take some shortcuts where possible, as long as the foundations and the underlying design is right, to get code running at CPL-3 at some point in 2H/2023. Looking at the points listed in the issue above, some of them are ready or almost ready (just not included in the main branch yet): * "Archive file in SVSM binary" is implemented * "Page allocator enhancements for reference counting pages" is implemented * "ELF loader" is implemented, there is a pending PR for it. The "RAM file system support" is currently being worked on. All of the listed points probably don't have a 'complete' state, I think we start with something very simple and improve from that later as needed. A primary example is the syscall interface, that will certainly evolve over time as people come along with their own ideas for other modules. The rough plan moving forward is: * Get RAM FS ready * Implement a task and address space abstraction which allows to map RAM FS file contents for CPL-3 * Task switch and sycall entry/exit * Example binary to run for initial tests (that will probably be worked on in parallel) When that is done we can look into how to get a vTPM into a binary and improve the underlying interface as required. Of course progress will be faster with more helping hands :-) There are also a lot of places that don't have a final design yet where help and discussions are beneficial. > At a conservative estimate, it looks like completion of all twelve > would take a team of people over a year to achieve. Some of these > tasks, like task switching and a syscall interface, really don't look > like they belong in a simple service module, like we were imagining an > SVSM would operate, is there some rationale behind this (or ideally > some architecture document that gives the justifications)? I think > what I'm really asking is can we get to CPL3 separation way sooner than > completion of all these tasks? We do not imaging the SVSM to be simple and small, we are imagining it to be secure and extensible. Of course it will always be smaller than a full-blown OS, but the vision is that it can do more than running a vTPM emulation. Also when we start looking into paravisor-like features like ReflectVC-handling later, the SVSM will certainly not be simple anymore. When I talked to people about the SVSM I often heard other interesting ideas what services it can provide. To make this possible and secure the SVSM needs the ability to run multiple modules at CPL-3. And a task concept with a simple FS to load those modules from is, in my opinion, the right approach. Yes, it takes more time than simpler and less flexible approaches, but as one of my favourite TV characters put it: "This is the Way" :-) Regards, -- Jörg Rödel jroedel@suse.de SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-03-21 9:29 [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP Jörg Rödel ` (2 preceding siblings ...) 2023-04-11 19:57 ` Tom Lendacky @ 2023-05-02 23:03 ` Tom Lendacky 2023-05-03 12:26 ` Jörg Rödel 3 siblings, 1 reply; 42+ messages in thread From: Tom Lendacky @ 2023-05-02 23:03 UTC (permalink / raw) To: Jörg Rödel, amd-sev-snp, linux-coco, kvm Cc: Carlos Bilbao, Klaus Kiwi On 3/21/23 04:29, Jörg Rödel wrote: > Hi, > > We are happy to announce that last week our secure VM service module > (SVSM) went public on GitHub for everyone to try it out and participate > in its further development. It is dual-licensed under the MIT and > APACHE-2.0 licenses. > > The project is written in Rust and can be cloned from: > > https://github.com/coconut-svsm/svsm > > There are also repositories in the github project with the Linux host and > guest, EDK2 and QEMU changes needed to run the SVSM and boot up a full > Linux guest. > > The SVSM repository contains an installation guide in the INSTALL.md > file and contributor hints in CONTRIBUTING.md. > > A blog entry with more details is here: > > https://www.suse.com/c/suse-open-sources-secure-vm-service-module-for-confidential-computing/ > > We also thank AMD for implementing and providing the necessary changes > to Linux and EDK2 to make an SVSM possible. > > Have a lot of fun! > I finally found the time to go through coconut-svsm and compare/contrast it to linux-svsm. Overall, they are very similar once loaded and running. I also took the time to preview this with a couple of our most prominent linux-svsm users before I sent it out. While both SVSM implementations use the Qemu Firmware Configuration (fw_cfg) interface, the coconut-svsm relies on it a bit more than linux-svsm. In either case, other interfaces may need to be supported in order for an SVSM to work with a VMM other than Qemu. Some of the main differences are (just an accounting, I'm not saying that one method is any better than the other): - Both SVSMs end up located in a memory slot outside of memory that is reported to the guest. Coconut-svsm gets the location and size from fwcfg, which is customizable via the Qemu command line. Linux-svsm gets the location and size from the build process and validates that location and size. - Coconut-svsm starts in stages. Stage1 starts in 32-bit protected mode just below the OVMF firmware (just below 4GB), copies stage2 and the SVSM to 64KB where further initialization is performed and ultimately with the SVSM being copied to its final location where execution continues. The current stage1 location could limit the size of the SVSM based on the MMIO layout of the guest. - Linux-svsm is loaded in its final location and starts in 64-bit long mode. This requires extra setup in Qemu for the VMSA, but no relocation is needed once it is loaded. - Coconut-svsm has developed its own IDT and pagetable support instead of using the x86_64 crate as linux-svsm does: - IDT: The main reason for the IDT support was to be able to customize the entry code, especially when CPL3 support is added. However, that can be done with the x86_64 crate by not using the "abi_x86_interrupt" feature. - Pagetables: Page table support can be tricky with the x86_64 crate. But in general I believe it could still be used. Coconut-svsm uses a dynamic offset- based approach for pagetables based on the final physical address location. This offset could be utilized in the x86_64 crate implementation. When CPL3 support comes around, that would require further investigation. - The advantage of using the x86_64 crate is getting added testing and fixes for issues that might not be immediately evident in a from scratch implementation. While not a issue, investigation could be done later to see if it is possible to move to those implementations (if desired). - Coconut-svsm uses the ACPI MADT table to detect and boot APs. This works well with Qemu or any VMM that builds the MADT table. The linux-svsm makes use of the GHCB APIC ID list NAE event. - Coconut-svsm does not measure the VMPL1 BSP VMSA directly. It uses set values that are measured as part of SVSM itself. This does prevent coconut-svsm from being able to launch VMPL1 using a different, measured BSP initial state. Linux-svsm, after performing some validation, does use a separately measured VMPL1 firmware BSP VMSA. - Coconut-svsm copies the original Secrets Page and the "frees" the memory for it. I couldn't tell if the memory is zeroed out or not, but something that should be looked at to ensure the VMPCK0 key is not leaked. Some questions for coconut-svsm: - Are there any concerns with using existing code/projects as submodules within coconut-svsm (e.g. OpenSSL or a software TPM implementation)? One of our design goals for linux-svsm was desirability to easily allow downstream users or products to, e.g., use their own crypto (e.g. company preferred) - Are you open to having maintainers outside of SUSE? There is some linux-svsm community concern about project governance and project priorities and release schedules. This wouldn't have to be AMD even, but we'd volunteer to help here if desired, but we'd like to foster a true community model for governance regardless. We'd love to hear thoughts on this from coconut-svsm folks. - On the subject of priorities, the number one priority for the linux-svsm project has been to quickly achieve production quality vTPM support. The support for this is being actively worked on by linux-svsm contributors and we'd want to find fastest path towards getting that redirected into coconut-svsm (possibly starting with CPL0 implementation until CPL3 support is available) and the project hardened for a release. I imagine there will be some competing priorities from coconut-svsm project currently, so wanted to get this out on the table from the beginning. Since we don't want to split resources or have competing projects, we are leaning towards moving our development resources over to the coconut-svsm project. I think we do need to sort out the governance question (maintainers, prioritization, release/schedule model, ...), but I don't see hard technical blockers. For others in the linux-svsm developer community, please ask questions or voice any concerns you may have so that we can see if they can be addressed. Thanks, Tom ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-05-02 23:03 ` Tom Lendacky @ 2023-05-03 12:26 ` Jörg Rödel 2023-05-03 15:24 ` Dionna Amalie Glaze ` (2 more replies) 0 siblings, 3 replies; 42+ messages in thread From: Jörg Rödel @ 2023-05-03 12:26 UTC (permalink / raw) To: Tom Lendacky; +Cc: amd-sev-snp, linux-coco, kvm, Carlos Bilbao, Klaus Kiwi Hi Tom, thanks for that comparision! On Tue, May 02, 2023 at 06:03:55PM -0500, Tom Lendacky wrote: > While both SVSM implementations use the Qemu Firmware Configuration > (fw_cfg) interface, the coconut-svsm relies on it a bit more than > linux-svsm. In either case, other interfaces may need to be supported in > order for an SVSM to work with a VMM other than Qemu. Right, that is something I have been thinking about. After I talked to a few others about it, I came to the conclusion that neither COCONUT nor linux-svsm use an optimal interface to request information from the HV. I think it would be best if we move to a model where the MADT and E820 tables from QEMU (or any other HV) are part of the measured initial memory image, to make that data trusted. But we can discuss that separately. > - Both SVSMs end up located in a memory slot outside of memory that is > reported to the guest. Coconut-svsm gets the location and size from > fwcfg, which is customizable via the Qemu command line. Linux-svsm gets > the location and size from the build process and validates that location > and size. Correct, COCONUT also has a fall-back where it just uses the last 16MB of guest RAM if the fw_cfg file is not there. That needs OVMF support, though. > - Pagetables: > Page table support can be tricky with the x86_64 crate. But in general > I believe it could still be used. Coconut-svsm uses a dynamic offset- > based approach for pagetables based on the final physical address > location. This offset could be utilized in the x86_64 crate > implementation. When CPL3 support comes around, that would require > further investigation. Yeah, COCONUT does not only use an offset mapping, it also has specific mappings for the per-cpu areas. Those are mapped at a fixed location, same with stacks, so the needs already go beyond an offset mapping. > - Coconut-svsm copies the original Secrets Page and the "frees" the memory > for it. I couldn't tell if the memory is zeroed out or not, but > something that should be looked at to ensure the VMPCK0 key is not > leaked. Thanks, that is a real issue. I just wrote a fix for that. > Some questions for coconut-svsm: > - Are there any concerns with using existing code/projects as submodules > within coconut-svsm (e.g. OpenSSL or a software TPM implementation)? > One of our design goals for linux-svsm was desirability to easily > allow downstream users or products to, e.g., use their own crypto > (e.g. company preferred) No concerns from my side to run any code you want in a CPL-3 module. This includes code which uses external libraries such as openssl or libtpm. The modules will be in an archive file packaged with the SVSM binary, so that everything that runs is measured at launch time. > - Are you open to having maintainers outside of SUSE? There is some > linux-svsm community concern about project governance and project > priorities and release schedules. This wouldn't have to be AMD even, > but we'd volunteer to help here if desired, but we'd like to foster a > true community model for governance regardless. We'd love to hear > thoughts on this from coconut-svsm folks. Yes, I am definitely willing to make the project more open and move to a maintainer-group model, no intention from my side to become a BDFL for the project. I just have no clear picture yet how the model should look like and how to get there. I will send a separate email to kick-start a discussion about that. > - On the subject of priorities, the number one priority for the > linux-svsm project has been to quickly achieve production quality vTPM > support. The support for this is being actively worked on by > linux-svsm contributors and we'd want to find fastest path towards > getting that redirected into coconut-svsm (possibly starting with CPL0 > implementation until CPL3 support is available) and the project > hardened for a release. I imagine there will be some competing > priorities from coconut-svsm project currently, so wanted to get this > out on the table from the beginning. That has been under discussion for some time, and honestly I think the approach taken is the main difference between linux-svsm and COCONUT. My position here is, and that comes with a big 'BUT', that I am not fundamentally opposed to having a temporary solution for the TPM until CPL-3 support is at a point where it can run a TPM module. And here come the 'BUT': Since the goal of having one project is to bundle community efforts, I think that the joint efforts are better targeted at getting CPL-3 support to a point where it can run modules. On that side some input and help is needed, especially to define the syscall interface so that it suits the needs of a TPM implementation. It is also not the case that CPL-3 support is out more than a year or so. The RamFS is almost ready, as is the archive file inclusion[1]. We will move to task management next, the goal is still to have basic support ready in 2H2023. [1] https://github.com/coconut-svsm/svsm/pull/27 If there is still a strong desire to have COCONUT with a TPM (running at CPL-0) before CPL-3 support is usable, then I can live with including code for that as a temporary solution. But linking huge amounts of C code (like openssl or a tpm lib) into the SVSM rust binary kind of contradicts the goals which made us using Rust for project in the first place. That is why I only see this as a temporary solution. > Since we don't want to split resources or have competing projects, we are > leaning towards moving our development resources over to the coconut-svsm > project. Great move, much appreciated, thanks a lot for that! Let's work together to make that happen. Regards, -- Jörg Rödel jroedel@suse.de SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-05-03 12:26 ` Jörg Rödel @ 2023-05-03 15:24 ` Dionna Amalie Glaze 2023-05-03 15:43 ` James Bottomley 2023-05-03 16:10 ` Daniel P. Berrangé 2023-05-03 16:51 ` Claudio Carvalho 2023-05-04 17:04 ` James Bottomley 2 siblings, 2 replies; 42+ messages in thread From: Dionna Amalie Glaze @ 2023-05-03 15:24 UTC (permalink / raw) To: Jörg Rödel Cc: Tom Lendacky, Klaus Kiwi, linux-coco, kvm, amd-sev-snp On Wed, May 3, 2023 at 5:27 AM Jörg Rödel <jroedel@suse.de> wrote: > > Hi Tom, > > thanks for that comparision! > > On Tue, May 02, 2023 at 06:03:55PM -0500, Tom Lendacky wrote: > > While both SVSM implementations use the Qemu Firmware Configuration > > (fw_cfg) interface, the coconut-svsm relies on it a bit more than > > linux-svsm. In either case, other interfaces may need to be supported in > > order for an SVSM to work with a VMM other than Qemu. > > Right, that is something I have been thinking about. After I talked to a > few others about it, I came to the conclusion that neither COCONUT nor > linux-svsm use an optimal interface to request information from the HV. > I think it would be best if we move to a model where the MADT and E820 > tables from QEMU (or any other HV) are part of the measured initial > memory image, to make that data trusted. But we can discuss that > separately. > > > - Both SVSMs end up located in a memory slot outside of memory that is > > reported to the guest. Coconut-svsm gets the location and size from > > fwcfg, which is customizable via the Qemu command line. Linux-svsm gets > > the location and size from the build process and validates that location > > and size. > > Correct, COCONUT also has a fall-back where it just uses the last 16MB > of guest RAM if the fw_cfg file is not there. That needs OVMF support, > though. > > > - Pagetables: > > Page table support can be tricky with the x86_64 crate. But in general > > I believe it could still be used. Coconut-svsm uses a dynamic offset- > > based approach for pagetables based on the final physical address > > location. This offset could be utilized in the x86_64 crate > > implementation. When CPL3 support comes around, that would require > > further investigation. > > Yeah, COCONUT does not only use an offset mapping, it also has specific > mappings for the per-cpu areas. Those are mapped at a fixed location, > same with stacks, so the needs already go beyond an offset mapping. > > > - Coconut-svsm copies the original Secrets Page and the "frees" the memory > > for it. I couldn't tell if the memory is zeroed out or not, but > > something that should be looked at to ensure the VMPCK0 key is not > > leaked. > > Thanks, that is a real issue. I just wrote a fix for that. > > > Some questions for coconut-svsm: > > - Are there any concerns with using existing code/projects as submodules > > within coconut-svsm (e.g. OpenSSL or a software TPM implementation)? > > One of our design goals for linux-svsm was desirability to easily > > allow downstream users or products to, e.g., use their own crypto > > (e.g. company preferred) > > No concerns from my side to run any code you want in a CPL-3 module. > This includes code which uses external libraries such as openssl or > libtpm. The modules will be in an archive file packaged with the SVSM > binary, so that everything that runs is measured at launch time. > > > - Are you open to having maintainers outside of SUSE? There is some > > linux-svsm community concern about project governance and project > > priorities and release schedules. This wouldn't have to be AMD even, > > but we'd volunteer to help here if desired, but we'd like to foster a > > true community model for governance regardless. We'd love to hear > > thoughts on this from coconut-svsm folks. > > Yes, I am definitely willing to make the project more open and move to a > maintainer-group model, no intention from my side to become a BDFL for > the project. I just have no clear picture yet how the model should look > like and how to get there. I will send a separate email to kick-start a > discussion about that. > > > - On the subject of priorities, the number one priority for the > > linux-svsm project has been to quickly achieve production quality vTPM > > support. The support for this is being actively worked on by > > linux-svsm contributors and we'd want to find fastest path towards > > getting that redirected into coconut-svsm (possibly starting with CPL0 > > implementation until CPL3 support is available) and the project > > hardened for a release. I imagine there will be some competing > > priorities from coconut-svsm project currently, so wanted to get this > > out on the table from the beginning. > > That has been under discussion for some time, and honestly I think > the approach taken is the main difference between linux-svsm and > COCONUT. My position here is, and that comes with a big 'BUT', that I am > not fundamentally opposed to having a temporary solution for the TPM > until CPL-3 support is at a point where it can run a TPM module. > > And here come the 'BUT': Since the goal of having one project is to > bundle community efforts, I think that the joint efforts are better > targeted at getting CPL-3 support to a point where it can run modules. > On that side some input and help is needed, especially to define the > syscall interface so that it suits the needs of a TPM implementation. > > It is also not the case that CPL-3 support is out more than a year or > so. The RamFS is almost ready, as is the archive file inclusion[1]. We > will move to task management next, the goal is still to have basic > support ready in 2H2023. > > [1] https://github.com/coconut-svsm/svsm/pull/27 > > If there is still a strong desire to have COCONUT with a TPM (running at > CPL-0) before CPL-3 support is usable, then I can live with including > code for that as a temporary solution. But linking huge amounts of C > code (like openssl or a tpm lib) into the SVSM rust binary kind of > contradicts the goals which made us using Rust for project in the first > place. That is why I only see this as a temporary solution. > > > Since we don't want to split resources or have competing projects, we are > > leaning towards moving our development resources over to the coconut-svsm > > project. > Not to throw a wrench in the works, but is it possible for us to have an RTMR protocol as a stop-gap between a fully paravirtualized vTPM and a fully internalized vTPM? The EFI protocol CC_MEASUREMENT_PROTOCOL is already standardized, and it can serve as a hardware-rooted integrity measure for a paravirtualized vTPM. This solution would further allow a TDX measured boot solution to be more thoroughly supported earlier, given that we'd need to have the RTMR event log replay logic implemented. > Great move, much appreciated, thanks a lot for that! Let's work together > to make that happen. > > Regards, > > -- > Jörg Rödel > jroedel@suse.de > > SUSE Software Solutions Germany GmbH > Frankenstraße 146 > 90461 Nürnberg > Germany > > (HRB 36809, AG Nürnberg) > Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman > -- -Dionna Glaze, PhD (she/her) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-05-03 15:24 ` Dionna Amalie Glaze @ 2023-05-03 15:43 ` James Bottomley 2023-05-03 16:10 ` Daniel P. Berrangé 1 sibling, 0 replies; 42+ messages in thread From: James Bottomley @ 2023-05-03 15:43 UTC (permalink / raw) To: Dionna Amalie Glaze, Jörg Rödel Cc: Tom Lendacky, Klaus Kiwi, linux-coco, kvm, amd-sev-snp On Wed, 2023-05-03 at 08:24 -0700, Dionna Amalie Glaze wrote: > On Wed, May 3, 2023 at 5:27 AM Jörg Rödel <jroedel@suse.de> wrote: [...] > > If there is still a strong desire to have COCONUT with a TPM > > (running at CPL-0) before CPL-3 support is usable, then I can live > > with including code for that as a temporary solution. But linking > > huge amounts of C code (like openssl or a tpm lib) into the SVSM > > rust binary kind of contradicts the goals which made us using Rust > > for project in the first place. That is why I only see this as a > > temporary solution. > > > > > Since we don't want to split resources or have competing > > > projects, we are leaning towards moving our development resources > > > over to the coconut-svsm project. > > > > Not to throw a wrench in the works, but is it possible for us to have > an RTMR protocol as a stop-gap between a fully paravirtualized vTPM > and a fully internalized vTPM? The EFI protocol > CC_MEASUREMENT_PROTOCOL is already standardized, and it can serve as > a hardware-rooted integrity measure for a paravirtualized vTPM. This > solution would further allow a TDX measured boot solution to be more > thoroughly supported earlier, given that we'd need to have the RTMR > event log replay logic implemented. From our point of view, having a large set of existing open source tools which speak the TPM protocol is the big benefit of the vTPM approach. Currently the partially closed source Amber attestation service, which is designed as the recipient of the RTMR protocol, only understands TDX (and SGX) attestation, so it would be more work than simply implementing a RTMR approach to make it attach to this tool. There would also be the huge problem of how we replicate the quoting enclave on SEV... James ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-05-03 15:24 ` Dionna Amalie Glaze 2023-05-03 15:43 ` James Bottomley @ 2023-05-03 16:10 ` Daniel P. Berrangé 1 sibling, 0 replies; 42+ messages in thread From: Daniel P. Berrangé @ 2023-05-03 16:10 UTC (permalink / raw) To: Dionna Amalie Glaze Cc: Jörg Rödel, Tom Lendacky, Klaus Kiwi, linux-coco, kvm, amd-sev-snp On Wed, May 03, 2023 at 08:24:10AM -0700, Dionna Amalie Glaze wrote: > On Wed, May 3, 2023 at 5:27 AM Jörg Rödel <jroedel@suse.de> wrote: > > > - On the subject of priorities, the number one priority for the > > > linux-svsm project has been to quickly achieve production quality vTPM > > > support. The support for this is being actively worked on by > > > linux-svsm contributors and we'd want to find fastest path towards > > > getting that redirected into coconut-svsm (possibly starting with CPL0 > > > implementation until CPL3 support is available) and the project > > > hardened for a release. I imagine there will be some competing > > > priorities from coconut-svsm project currently, so wanted to get this > > > out on the table from the beginning. > > > > That has been under discussion for some time, and honestly I think > > the approach taken is the main difference between linux-svsm and > > COCONUT. My position here is, and that comes with a big 'BUT', that I am > > not fundamentally opposed to having a temporary solution for the TPM > > until CPL-3 support is at a point where it can run a TPM module. > > > > And here come the 'BUT': Since the goal of having one project is to > > bundle community efforts, I think that the joint efforts are better > > targeted at getting CPL-3 support to a point where it can run modules. > > On that side some input and help is needed, especially to define the > > syscall interface so that it suits the needs of a TPM implementation. > > > > It is also not the case that CPL-3 support is out more than a year or > > so. The RamFS is almost ready, as is the archive file inclusion[1]. We > > will move to task management next, the goal is still to have basic > > support ready in 2H2023. > > > > [1] https://github.com/coconut-svsm/svsm/pull/27 > > > > If there is still a strong desire to have COCONUT with a TPM (running at > > CPL-0) before CPL-3 support is usable, then I can live with including > > code for that as a temporary solution. But linking huge amounts of C > > code (like openssl or a tpm lib) into the SVSM rust binary kind of > > contradicts the goals which made us using Rust for project in the first > > place. That is why I only see this as a temporary solution. > > > > > Since we don't want to split resources or have competing projects, we are > > > leaning towards moving our development resources over to the coconut-svsm > > > project. > > > > Not to throw a wrench in the works, but is it possible for us to have > an RTMR protocol as a stop-gap between a fully paravirtualized vTPM > and a fully internalized vTPM? The EFI protocol > CC_MEASUREMENT_PROTOCOL is already standardized, and it can serve as a > hardware-rooted integrity measure for a paravirtualized vTPM. This > solution would further allow a TDX measured boot solution to be more > thoroughly supported earlier, given that we'd need to have the RTMR > event log replay logic implemented. IMHO it would be preferrable if RTMR was exposed to as little as possible. The less special cases we have to build into applications / projects related to confidential virt, the better off we'll be. The use of industry standard TPMs with PCRs reduces the matrix that work that is needed to support confidential virt across the stack. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-05-03 12:26 ` Jörg Rödel 2023-05-03 15:24 ` Dionna Amalie Glaze @ 2023-05-03 16:51 ` Claudio Carvalho 2023-05-03 17:16 ` Alexander Graf 2023-05-05 15:34 ` Jörg Rödel 2023-05-04 17:04 ` James Bottomley 2 siblings, 2 replies; 42+ messages in thread From: Claudio Carvalho @ 2023-05-03 16:51 UTC (permalink / raw) To: Jörg Rödel, Tom Lendacky Cc: amd-sev-snp, linux-coco, kvm, Carlos Bilbao, Klaus Kiwi Hi Jorg, On Wed, 2023-05-03 at 14:26 +0200, Jörg Rödel wrote: > > > - Are you open to having maintainers outside of SUSE? There is some > > linux-svsm community concern about project governance and project > > priorities and release schedules. This wouldn't have to be AMD even, > > but we'd volunteer to help here if desired, but we'd like to foster a > > true community model for governance regardless. We'd love to hear > > thoughts on this from coconut-svsm folks. > > Yes, I am definitely willing to make the project more open and move to a > maintainer-group model, no intention from my side to become a BDFL for > the project. I just have no clear picture yet how the model should look > like and how to get there. I will send a separate email to kick-start a > discussion about that. > Thanks. I would be happy to collaborate in that discussion. > > - On the subject of priorities, the number one priority for the > > linux-svsm project has been to quickly achieve production quality vTPM > > support. The support for this is being actively worked on by > > linux-svsm contributors and we'd want to find fastest path towards > > getting that redirected into coconut-svsm (possibly starting with CPL0 > > implementation until CPL3 support is available) and the project > > hardened for a release. I imagine there will be some competing > > priorities from coconut-svsm project currently, so wanted to get this > > out on the table from the beginning. > > That has been under discussion for some time, and honestly I think > the approach taken is the main difference between linux-svsm and > COCONUT. My position here is, and that comes with a big 'BUT', that I am > not fundamentally opposed to having a temporary solution for the TPM > until CPL-3 support is at a point where it can run a TPM module. > > And here come the 'BUT': Since the goal of having one project is to > bundle community efforts, I think that the joint efforts are better > targeted at getting CPL-3 support to a point where it can run modules. > On that side some input and help is needed, especially to define the > syscall interface so that it suits the needs of a TPM implementation. > > It is also not the case that CPL-3 support is out more than a year or > so. The RamFS is almost ready, as is the archive file inclusion[1]. We > will move to task management next, the goal is still to have basic > support ready in 2H2023. > > [1] https://github.com/coconut-svsm/svsm/pull/27 > > If there is still a strong desire to have COCONUT with a TPM (running at > CPL-0) before CPL-3 support is usable, then I can live with including > code for that as a temporary solution. But linking huge amounts of C > code (like openssl or a tpm lib) into the SVSM rust binary kind of > contradicts the goals which made us using Rust for project in the first > place. That is why I only see this as a temporary solution. > > I think the crypto support requires more design discussion since it is required in multiple places. The experience I've had adding SVSM-vTPM support is that the SVSM needs crypto for requesting an attestation report (SNP_GUEST_REQUEST messages sent to the security processor PSP have to be encrypted with AES_GCM) and the vTPM also needs crypto for the TPM crypto operations. We could just duplicate the crypto library, or find a way to share it (e.g. vdso approach). For the SVSM, it would be rust code talking to the crypto library; for the vTPM it would be the vTPM (most likely an existing C implementation) talking to the crypto library. Regards, Claudio ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-05-03 16:51 ` Claudio Carvalho @ 2023-05-03 17:16 ` Alexander Graf 2023-05-05 15:34 ` Jörg Rödel 1 sibling, 0 replies; 42+ messages in thread From: Alexander Graf @ 2023-05-03 17:16 UTC (permalink / raw) To: Claudio Carvalho, Jörg Rödel, Tom Lendacky Cc: amd-sev-snp, linux-coco, kvm, Carlos Bilbao, Klaus Kiwi On 03.05.23 18:51, Claudio Carvalho wrote: > > Hi Jorg, > > On Wed, 2023-05-03 at 14:26 +0200, Jörg Rödel wrote: >>> - Are you open to having maintainers outside of SUSE? There is some >>> linux-svsm community concern about project governance and project >>> priorities and release schedules. This wouldn't have to be AMD even, >>> but we'd volunteer to help here if desired, but we'd like to foster a >>> true community model for governance regardless. We'd love to hear >>> thoughts on this from coconut-svsm folks. >> Yes, I am definitely willing to make the project more open and move to a >> maintainer-group model, no intention from my side to become a BDFL for >> the project. I just have no clear picture yet how the model should look >> like and how to get there. I will send a separate email to kick-start a >> discussion about that. >> > Thanks. I would be happy to collaborate in that discussion. > >>> - On the subject of priorities, the number one priority for the >>> linux-svsm project has been to quickly achieve production quality vTPM >>> support. The support for this is being actively worked on by >>> linux-svsm contributors and we'd want to find fastest path towards >>> getting that redirected into coconut-svsm (possibly starting with CPL0 >>> implementation until CPL3 support is available) and the project >>> hardened for a release. I imagine there will be some competing >>> priorities from coconut-svsm project currently, so wanted to get this >>> out on the table from the beginning. >> That has been under discussion for some time, and honestly I think >> the approach taken is the main difference between linux-svsm and >> COCONUT. My position here is, and that comes with a big 'BUT', that I am >> not fundamentally opposed to having a temporary solution for the TPM >> until CPL-3 support is at a point where it can run a TPM module. >> >> And here come the 'BUT': Since the goal of having one project is to >> bundle community efforts, I think that the joint efforts are better >> targeted at getting CPL-3 support to a point where it can run modules. >> On that side some input and help is needed, especially to define the >> syscall interface so that it suits the needs of a TPM implementation. >> >> It is also not the case that CPL-3 support is out more than a year or >> so. The RamFS is almost ready, as is the archive file inclusion[1]. We >> will move to task management next, the goal is still to have basic >> support ready in 2H2023. >> >> [1] https://github.com/coconut-svsm/svsm/pull/27 >> >> If there is still a strong desire to have COCONUT with a TPM (running at >> CPL-0) before CPL-3 support is usable, then I can live with including >> code for that as a temporary solution. But linking huge amounts of C >> code (like openssl or a tpm lib) into the SVSM rust binary kind of >> contradicts the goals which made us using Rust for project in the first >> place. That is why I only see this as a temporary solution. >> >> > I think the crypto support requires more design discussion since it is required > in multiple places. > > The experience I've had adding SVSM-vTPM support is that the SVSM needs crypto > for requesting an attestation report (SNP_GUEST_REQUEST messages sent to the > security processor PSP have to be encrypted with AES_GCM) and the vTPM also > needs crypto for the TPM crypto operations. We could just duplicate the crypto > library, or find a way to share it (e.g. vdso approach). > > For the SVSM, it would be rust code talking to the crypto library; for the vTPM > it would be the vTPM (most likely an existing C implementation) talking to the > crypto library. With SVSM, we're reintroducing a new way of doing SMM inside virtual machines: A higher privilege mode than can transparently run arbitrary code at arbitrary times, invisible to the OS. That means any bug in that code is fatal. TPM implementations may receive untrusted inputs from user space. That means we need to confine it as strongly as possible: The syscall interface needs to be as minimal and static (no dynamic memory allocations, object livecycles, etc) as possible. The less memory we share between the TPM implementation and anything outside, the better. Any memory sharing is a potential side channel attack target (data) or side channel training target (code). So to fold this into the paragraph above: Please don't overthink / overengineer this. Applications should be as self contained as possible. No VDSO, no direct linking. Ideally even fully static at boot memory allocation. Alex Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-05-03 16:51 ` Claudio Carvalho 2023-05-03 17:16 ` Alexander Graf @ 2023-05-05 15:34 ` Jörg Rödel 2023-05-05 15:47 ` Daniel P. Berrangé 1 sibling, 1 reply; 42+ messages in thread From: Jörg Rödel @ 2023-05-05 15:34 UTC (permalink / raw) To: Claudio Carvalho Cc: Tom Lendacky, amd-sev-snp, linux-coco, kvm, Carlos Bilbao, Klaus Kiwi Hi Claudio, On Wed, May 03, 2023 at 12:51:17PM -0400, Claudio Carvalho wrote: > Thanks. I would be happy to collaborate in that discussion. Great, I will send out that email early next week to get the discussion rolling. > I think the crypto support requires more design discussion since it is required > in multiple places. > > The experience I've had adding SVSM-vTPM support is that the SVSM needs crypto > for requesting an attestation report (SNP_GUEST_REQUEST messages sent to the > security processor PSP have to be encrypted with AES_GCM) and the vTPM also > needs crypto for the TPM crypto operations. We could just duplicate the crypto > library, or find a way to share it (e.g. vdso approach). > > For the SVSM, it would be rust code talking to the crypto library; for the vTPM > it would be the vTPM (most likely an existing C implementation) talking to the > crypto library. Right, where to place and how to share the crypto code needs more discussion, there are multiple possible approaches. I have seen that you have a talk at KVM Forum, so we can meet there in a larger group and discuss those and other questions in person. I think from this thread and other discussions happening it became clear that there are currently a lot of different opinions on what the SVSM should do and how it should look like. It would be great if we as a community can get closer together on those questions (which is certainly helpful for combining efforts). Regards, -- Jörg Rödel jroedel@suse.de SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-05-05 15:34 ` Jörg Rödel @ 2023-05-05 15:47 ` Daniel P. Berrangé 0 siblings, 0 replies; 42+ messages in thread From: Daniel P. Berrangé @ 2023-05-05 15:47 UTC (permalink / raw) To: Jörg Rödel Cc: Claudio Carvalho, Tom Lendacky, amd-sev-snp, linux-coco, kvm, Carlos Bilbao, Klaus Kiwi On Fri, May 05, 2023 at 05:34:20PM +0200, Jörg Rödel wrote: > Hi Claudio, > > On Wed, May 03, 2023 at 12:51:17PM -0400, Claudio Carvalho wrote: > > Thanks. I would be happy to collaborate in that discussion. > > Great, I will send out that email early next week to get the discussion > rolling. > > > I think the crypto support requires more design discussion since it is required > > in multiple places. > > > > The experience I've had adding SVSM-vTPM support is that the SVSM needs crypto > > for requesting an attestation report (SNP_GUEST_REQUEST messages sent to the > > security processor PSP have to be encrypted with AES_GCM) and the vTPM also > > needs crypto for the TPM crypto operations. We could just duplicate the crypto > > library, or find a way to share it (e.g. vdso approach). > > > > For the SVSM, it would be rust code talking to the crypto library; for the vTPM > > it would be the vTPM (most likely an existing C implementation) talking to the > > crypto library. > > Right, where to place and how to share the crypto code needs more > discussion, there are multiple possible approaches. I have seen that you > have a talk at KVM Forum, so we can meet there in a larger group and > discuss those and other questions in person. Yep, we should probably do a BoF session on the topic of SVSM for anyone interested who's attending KVM Forum. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-05-03 12:26 ` Jörg Rödel 2023-05-03 15:24 ` Dionna Amalie Glaze 2023-05-03 16:51 ` Claudio Carvalho @ 2023-05-04 17:04 ` James Bottomley 2023-05-05 12:35 ` Christophe de Dinechin 2023-05-05 15:02 ` Jörg Rödel 2 siblings, 2 replies; 42+ messages in thread From: James Bottomley @ 2023-05-04 17:04 UTC (permalink / raw) To: Jörg Rödel, Tom Lendacky Cc: Klaus Kiwi, linux-coco, kvm, amd-sev-snp On Wed, 2023-05-03 at 14:26 +0200, Jörg Rödel wrote: > On Tue, May 02, 2023 at 06:03:55PM -0500, Tom Lendacky wrote: [...] > > - On the subject of priorities, the number one priority for the > > linux-svsm project has been to quickly achieve production > > quality vTPM support. The support for this is being actively worked > > on by linux-svsm contributors and we'd want to find fastest path > > towards getting that redirected into coconut-svsm (possibly > > starting with CPL0 > > implementation until CPL3 support is available) and the project > > hardened for a release. I imagine there will be some competing > > priorities from coconut-svsm project currently, so wanted to > > get this out on the table from the beginning. > > That has been under discussion for some time, and honestly I think > the approach taken is the main difference between linux-svsm and > COCONUT. My position here is, and that comes with a big 'BUT', that I > am not fundamentally opposed to having a temporary solution for the > TPM until CPL-3 support is at a point where it can run a TPM module. OK, so this, for IBM, is directly necessary. We have the vTPM pull request about ready to go and we'll probably send it still to the AMD SVSM. Given that the AMD SVSM already has the openssl library and the attestation report support, do you want to pull them into coconut directly so we can base a coconut vTPM pull request on that? > And here come the 'BUT': Since the goal of having one project is to > bundle community efforts, I think that the joint efforts are better > targeted at getting CPL-3 support to a point where it can run > modules. On that side some input and help is needed, especially to > define the syscall interface so that it suits the needs of a TPM > implementation. Crypto support in ring-0 is unavoidable if we want to retain control of the VMPCK0 key in ring-0. I can't see us giving it to ring-3 because that would give up control of the SVSM identity and basically make the ring-0 separation useless because you can compromise ring-3 and get the key and then communicate with the PSP as the SVSM. I think the above problem also indicates no-one really has a fully thought out security model that shows practically how ring-3 improves the security posture. So I really think starting in ring-0 and then moving pieces to ring-3 and discussing whether this materially improves the security posture based on the code and how it operates gets us around the lack of understanding of the security model because we proceed by evolution. The next question that's going to arise is *where* the crypto libraries should reside. Given they're somewhat large, duplicating them for every cpl-3 application plus cpl-3 seems wasteful, so some type of vdso model sounds better (and might work instead of a syscall interfaces for cpl-0 services that are pure code). > It is also not the case that CPL-3 support is out more than a year or > so. The RamFS is almost ready, as is the archive file inclusion[1]. > We will move to task management next, the goal is still to have basic > support ready in 2H2023. > > [1] https://github.com/coconut-svsm/svsm/pull/27 Well, depending on how you order them, possibly. The vTPM has a simple request/response model, so it really doesn't have much need of a scheduler for instance. And we could obviously bring up cpl-3 before a module loader/ram filesystem and move to that later. > If there is still a strong desire to have COCONUT with a TPM (running > at CPL-0) before CPL-3 support is usable, then I can live with > including code for that as a temporary solution. But linking huge > amounts of C code (like openssl or a tpm lib) into the SVSM rust > binary kind of contradicts the goals which made us using Rust for > project in the first place. That is why I only see this as a > temporary solution. I'm not sure it will be. If some cloud or distro wants to shoot for FIPS compliance of the SVSM, for instance, a requirement will likely be to use a FIPS certified crypto library ... and they're all currently in C. That's not to say we shouldn't aim for minimizing the C dependencies, but I don't see a "pure rust or else" approach facilitating the initial utility of the project. James ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-05-04 17:04 ` James Bottomley @ 2023-05-05 12:35 ` Christophe de Dinechin 2023-05-06 12:48 ` James Bottomley 2023-05-05 15:02 ` Jörg Rödel 1 sibling, 1 reply; 42+ messages in thread From: Christophe de Dinechin @ 2023-05-05 12:35 UTC (permalink / raw) To: jejb Cc: Jörg Rödel, Tom Lendacky, Klaus Kiwi, linux-coco, kvm, amd-sev-snp On 2023-05-04 at 13:04 -04, James Bottomley <jejb@linux.ibm.com> wrote... > On Wed, 2023-05-03 at 14:26 +0200, Jörg Rödel wrote: >> On Tue, May 02, 2023 at 06:03:55PM -0500, Tom Lendacky wrote: > [...] >> > - On the subject of priorities, the number one priority for the >> > linux-svsm project has been to quickly achieve production >> > quality vTPM support. The support for this is being actively worked >> > on by linux-svsm contributors and we'd want to find fastest path >> > towards getting that redirected into coconut-svsm (possibly >> > starting with CPL0 >> > implementation until CPL3 support is available) and the project >> > hardened for a release. I imagine there will be some competing >> > priorities from coconut-svsm project currently, so wanted to >> > get this out on the table from the beginning. >> >> That has been under discussion for some time, and honestly I think >> the approach taken is the main difference between linux-svsm and >> COCONUT. My position here is, and that comes with a big 'BUT', that I >> am not fundamentally opposed to having a temporary solution for the >> TPM until CPL-3 support is at a point where it can run a TPM module. > > OK, so this, for IBM, is directly necessary. We have the vTPM pull > request about ready to go and we'll probably send it still to the AMD > SVSM. Given that the AMD SVSM already has the openssl library and the > attestation report support, do you want to pull them into coconut > directly so we can base a coconut vTPM pull request on that? > >> And here come the 'BUT': Since the goal of having one project is to >> bundle community efforts, I think that the joint efforts are better >> targeted at getting CPL-3 support to a point where it can run >> modules. On that side some input and help is needed, especially to >> define the syscall interface so that it suits the needs of a TPM >> implementation. > > Crypto support in ring-0 is unavoidable if we want to retain control of > the VMPCK0 key in ring-0. I can't see us giving it to ring-3 because > that would give up control of the SVSM identity and basically make the > ring-0 separation useless because you can compromise ring-3 and get the > key and then communicate with the PSP as the SVSM. I'm a but confused regarding the roles that VMPL vs rings is in the security model here. In particular, I assume that any attack on ring3 would still have to cross either the VMPL boundary (if coming from the guest) or the TEE boundary (if coming from the host). > > I think the above problem also indicates no-one really has a fully > thought out security model that shows practically how ring-3 improves > the security posture. So I really think starting in ring-0 and then > moving pieces to ring-3 and discussing whether this materially improves > the security posture based on the code and how it operates gets us > around the lack of understanding of the security model because we > proceed by evolution. And there is definitely a lot of complexity added by supporting ring3. You are essentially getting the complexity of a "real" operating system. By contrast, TDX is providing the same kind of isolation with secure enclaves, but at least the base OS kernel is shared. The expected benefit is to be able to run more complex code from ring3 with a better way to handle malfunctions, faults, whatever. At least that's the way I read it. So it's a way to write software in a more modular way. IIUC, the ring-3 modules of the SVSM would still be at VMPL0, so presumably, not accesible from host or guest. If we consider this property as strong, then do we really care entrusting ring3 with sensitive data? > > The next question that's going to arise is *where* the crypto libraries > should reside. Given they're somewhat large, duplicating them for > every cpl-3 application plus cpl-3 seems wasteful, so some type of vdso > model sounds better (and might work instead of a syscall interfaces for > cpl-0 services that are pure code). I don't understand what you call "pure code". I presume you mean "code that does not need to access ring0 data"? > >> It is also not the case that CPL-3 support is out more than a year or >> so. The RamFS is almost ready, as is the archive file inclusion[1]. >> We will move to task management next, the goal is still to have basic >> support ready in 2H2023. >> >> [1] https://github.com/coconut-svsm/svsm/pull/27 > > Well, depending on how you order them, possibly. The vTPM has a simple > request/response model, so it really doesn't have much need of a > scheduler for instance. And we could obviously bring up cpl-3 before a > module loader/ram filesystem and move to that later. > >> If there is still a strong desire to have COCONUT with a TPM (running >> at CPL-0) before CPL-3 support is usable, then I can live with >> including code for that as a temporary solution. But linking huge >> amounts of C code (like openssl or a tpm lib) into the SVSM rust >> binary kind of contradicts the goals which made us using Rust for >> project in the first place. That is why I only see this as a >> temporary solution. > > I'm not sure it will be. If some cloud or distro wants to shoot for > FIPS compliance of the SVSM, for instance, a requirement will likely be > to use a FIPS certified crypto library ... and they're all currently in > C. That's not to say we shouldn't aim for minimizing the C > dependencies, but I don't see a "pure rust or else" approach > facilitating the initial utility of the project. > > James -- Cheers, Christophe de Dinechin (https://c3d.github.io) Freedom Covenant (https://github.com/c3d/freedom-covenant) Theory of Incomplete Measurements (https://c3d.github.io/TIM) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-05-05 12:35 ` Christophe de Dinechin @ 2023-05-06 12:48 ` James Bottomley 2023-05-08 5:16 ` Alexander Graf 0 siblings, 1 reply; 42+ messages in thread From: James Bottomley @ 2023-05-06 12:48 UTC (permalink / raw) To: Christophe de Dinechin Cc: Jörg Rödel, Tom Lendacky, Klaus Kiwi, linux-coco, kvm, amd-sev-snp On Fri, 2023-05-05 at 14:35 +0200, Christophe de Dinechin wrote: > > On 2023-05-04 at 13:04 -04, James Bottomley <jejb@linux.ibm.com> > wrote... > > On Wed, 2023-05-03 at 14:26 +0200, Jörg Rödel wrote: [...] > > > And here come the 'BUT': Since the goal of having one project is > > > to bundle community efforts, I think that the joint efforts are > > > better targeted at getting CPL-3 support to a point where it can > > > run modules. On that side some input and help is needed, > > > especially to define the syscall interface so that it suits the > > > needs of a TPM implementation. > > > > Crypto support in ring-0 is unavoidable if we want to retain > > control of the VMPCK0 key in ring-0. I can't see us giving it to > > ring-3 because that would give up control of the SVSM identity and > > basically make the ring-0 separation useless because you can > > compromise ring-3 and get the key and then communicate with the PSP > > as the SVSM. > > I'm a but confused regarding the roles that VMPL vs rings is in the > security model here. Heh, I think that goes for everyone, which is why I'm fishing for information about the security model. I don't think its enough to blindly claim running at cpl3 gives more security, you have to have a threat model that demonstrates it. > In particular, I assume that any attack on ring3 would > still have to cross either the VMPL boundary (if coming from the > guest) or the TEE boundary (if coming from the host). I think the attack theory is more like a privilege escalation: you induce the SVSM to take a fault through its normal API mechanism by crafting bad data (this means the runtime attack can only come from the guest since the host doesn't get access to the SVSM at runtime, although it could craft bad configuration data for boot time). Assuming a successful exploit, the attacker now has the ability to run code in the compromised module. For a unitary SVSM, that would give control of the entire SVSM. For ring 0/3 separation, it should only give control of the compromised module, which we're assuming is ring 3 code. However, you're right, in that the attacker now has the ability to execute VPML0 code, except that some privileged instructions (like PVALIDATE) can only execute at ring 0, so the attack ability is slightly more limited. I've always considered the gold standard exploit of the SVSM to be one that allows you to fake attestation reports, since then it's game over as far as remote verification goes, which is why I want the VMPCK0 key (the communication key VPML0 uses to get VMPL0 specific attestation reports from the PSP) to be closely guarded at ring 0, making it harder to compromise remote attestation via exploits. The flip side is that, assuming the vTPM is the compromised service, you've already got the ability to fake TPM based runtime attestation, so its still game over from the remote attestation point of view. This leads me to conclude that it really doesn't matter where security critical protocols run, and the only real advantage of the ring 0/3 separation would come into play if the SVSM had some non-security critical protocols and it's not clear if it ever will. > > I think the above problem also indicates no-one really has a fully > > thought out security model that shows practically how ring-3 > > improves the security posture. So I really think starting in ring- > > 0 and then moving pieces to ring-3 and discussing whether this > > materially improves the security posture based on the code and how > > it operates gets us around the lack of understanding of the > > security model because we proceed by evolution. > > And there is definitely a lot of complexity added by supporting > ring3. You are essentially getting the complexity of a "real" > operating system. By contrast, TDX is providing the same kind of > isolation with secure enclaves, but at least the base OS kernel is > shared. > > The expected benefit is to be able to run more complex code from > ring3 with a better way to handle malfunctions, faults, whatever. At > least that's the way I read it. So it's a way to write software in a > more modular way. Yes, but is that a benefit? If one of the protocol modules faults, I think you'd rather have a hard failure of the whole confidential VM than a restart that gives an attacker more leeway to craft a compromise. > IIUC, the ring-3 modules of the SVSM would still be at VMPL0, so > presumably, not accesible from host or guest. If we consider this > property as strong, then do we really care entrusting ring3 with > sensitive data? Well, as I said above, I think for security critical modules, it doesn't matter where they run, so perhaps we don't care, but equally there's not much security benefit to ring 0/3 separation either. > > The next question that's going to arise is *where* the crypto > > libraries should reside. Given they're somewhat large, duplicating > > them for every cpl-3 application plus cpl-3 seems wasteful, so some > > type of vdso model sounds better (and might work instead of a > > syscall interfaces for cpl-0 services that are pure code). > > I don't understand what you call "pure code". I presume you mean > "code that does not need to access ring0 data"? I was meaning a VDSO like model, where the openssl crypto code could be exported from ring-0 as an executable library, but the data would live with the corresponding consumer, so it could be used by the SVSM body at ring-0 with any crypto data being held at ring-0 and inaccessible to ring-3 consumers of the crypto code. James ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-05-06 12:48 ` James Bottomley @ 2023-05-08 5:16 ` Alexander Graf 0 siblings, 0 replies; 42+ messages in thread From: Alexander Graf @ 2023-05-08 5:16 UTC (permalink / raw) To: jejb, Christophe de Dinechin Cc: Jörg Rödel, Tom Lendacky, Klaus Kiwi, linux-coco, kvm, amd-sev-snp On 06.05.23 14:48, James Bottomley wrote: > > > On Fri, 2023-05-05 at 14:35 +0200, Christophe de Dinechin wrote: >> On 2023-05-04 at 13:04 -04, James Bottomley <jejb@linux.ibm.com> >> wrote... >>> On Wed, 2023-05-03 at 14:26 +0200, Jörg Rödel wrote: > [...] >>>> And here come the 'BUT': Since the goal of having one project is >>>> to bundle community efforts, I think that the joint efforts are >>>> better targeted at getting CPL-3 support to a point where it can >>>> run modules. On that side some input and help is needed, >>>> especially to define the syscall interface so that it suits the >>>> needs of a TPM implementation. >>> Crypto support in ring-0 is unavoidable if we want to retain >>> control of the VMPCK0 key in ring-0. I can't see us giving it to >>> ring-3 because that would give up control of the SVSM identity and >>> basically make the ring-0 separation useless because you can >>> compromise ring-3 and get the key and then communicate with the PSP >>> as the SVSM. >> I'm a but confused regarding the roles that VMPL vs rings is in the >> security model here. > Heh, I think that goes for everyone, which is why I'm fishing for > information about the security model. I don't think its enough to > blindly claim running at cpl3 gives more security, you have to have a > threat model that demonstrates it. > >> In particular, I assume that any attack on ring3 would >> still have to cross either the VMPL boundary (if coming from the >> guest) or the TEE boundary (if coming from the host). > I think the attack theory is more like a privilege escalation: you > induce the SVSM to take a fault through its normal API mechanism by > crafting bad data (this means the runtime attack can only come from the > guest since the host doesn't get access to the SVSM at runtime, > although it could craft bad configuration data for boot time). > > Assuming a successful exploit, the attacker now has the ability to run > code in the compromised module. For a unitary SVSM, that would give > control of the entire SVSM. For ring 0/3 separation, it should only > give control of the compromised module, which we're assuming is ring 3 > code. However, you're right, in that the attacker now has the ability > to execute VPML0 code, except that some privileged instructions (like > PVALIDATE) can only execute at ring 0, so the attack ability is > slightly more limited. I think we're munging 2 things into the same conversation: * Running code at lower privilege level so code execution attacks can not elevate beyond that code's area of responsibility * Running code with its own address space, so accidental data leaks don't leak additionally sensitive information I personally care more about the latter than the former, mostly also because of speculation side channel attacks. I really don't want to be in a world where you can train the branch predictor of the vTPM to access kernel memory. Code execution gadgets are less prevalent, especially if you use rust as programming language. > I've always considered the gold standard exploit of the SVSM to be one > that allows you to fake attestation reports, since then it's game over > as far as remote verification goes, which is why I want the VMPCK0 key > (the communication key VPML0 uses to get VMPL0 specific attestation > reports from the PSP) to be closely guarded at ring 0, making it harder > to compromise remote attestation via exploits. IMHO that's slightly too focused on the attestation part of the story. Imagine an environment where someone managed to gain RCE in a random user space application of your VM that has no access to actual secrets / PEI / etc. Like a monitoring service running log4j :). That service however may have access to /dev/tpm0 (via whatever means) and thus is able to craft requests to the vTPM. In this situation, you really want to ensure that the vTPM has absolutely 0 access to any memory it doesn't have to. Even better if you can ensure it stays that way (read: no way to write CR3). > The flip side is that, assuming the vTPM is the compromised service, > you've already got the ability to fake TPM based runtime attestation, > so its still game over from the remote attestation point of view. This > leads me to conclude that it really doesn't matter where security > critical protocols run, and the only real advantage of the ring 0/3 > separation would come into play if the SVSM had some non-security > critical protocols and it's not clear if it ever will. I think going forward we will have to move the UEFI Variable Runtime Services into SVSM as well. There is no virtual SMM mode in SEV-SNP that I'm aware of and trusting the host environment for UEFI Secure Boot may or may not be desirable. > >>> I think the above problem also indicates no-one really has a fully >>> thought out security model that shows practically how ring-3 >>> improves the security posture. So I really think starting in ring- >>> 0 and then moving pieces to ring-3 and discussing whether this >>> materially improves the security posture based on the code and how >>> it operates gets us around the lack of understanding of the >>> security model because we proceed by evolution. >> And there is definitely a lot of complexity added by supporting >> ring3. You are essentially getting the complexity of a "real" >> operating system. By contrast, TDX is providing the same kind of >> isolation with secure enclaves, but at least the base OS kernel is >> shared. >> >> The expected benefit is to be able to run more complex code from >> ring3 with a better way to handle malfunctions, faults, whatever. At >> least that's the way I read it. So it's a way to write software in a >> more modular way. > Yes, but is that a benefit? If one of the protocol modules faults, I > think you'd rather have a hard failure of the whole confidential VM > than a restart that gives an attacker more leeway to craft a > compromise. It's also about the ability to detect failure. The more guard rails you put in, the more likely you can identify when something goes off. Whether we then attempt to continue execution or consider it a fatal event is up to us. The worst case would be a fully populated linear address space where any pointer derailing is completely undetectable. > >> IIUC, the ring-3 modules of the SVSM would still be at VMPL0, so >> presumably, not accesible from host or guest. If we consider this >> property as strong, then do we really care entrusting ring3 with >> sensitive data? > Well, as I said above, I think for security critical modules, it > doesn't matter where they run, so perhaps we don't care, but equally > there's not much security benefit to ring 0/3 separation either. > >>> The next question that's going to arise is *where* the crypto >>> libraries should reside. Given they're somewhat large, duplicating >>> them for every cpl-3 application plus cpl-3 seems wasteful, so some >>> type of vdso model sounds better (and might work instead of a >>> syscall interfaces for cpl-0 services that are pure code). >> I don't understand what you call "pure code". I presume you mean >> "code that does not need to access ring0 data"? > I was meaning a VDSO like model, where the openssl crypto code could be > exported from ring-0 as an executable library, but the data would live > with the corresponding consumer, so it could be used by the SVSM body > at ring-0 with any crypto data being held at ring-0 and inaccessible to > ring-3 consumers of the crypto code. Have a look at this presentation, get all the way to the on-screen keyboard sniffer and then faithfully tell me again that you believe sharing code (and AES tables) is a good idea :) https://media.ccc.de/v/33c3-8044-what_could_possibly_go_wrong_with_insert_x86_instruction_here I also feel like I'm missing something obvious in the conversation. Let's imagine the worst case for size I can think of today. In that case, the main SVSM code, vTPM code as well as UEFI variable store would duplicate (parts of) crypto libraries. Let's again imagine the worst and no proper LTO, so we need to link all of openssl into all 2 components plus the Rust based crypto which we again assume to be as large. In this worst case scenario not sharing the code wastes less than 1MiB altogether. That doesn't sound like something to optimize for at all at this stage? Alex Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP 2023-05-04 17:04 ` James Bottomley 2023-05-05 12:35 ` Christophe de Dinechin @ 2023-05-05 15:02 ` Jörg Rödel 1 sibling, 0 replies; 42+ messages in thread From: Jörg Rödel @ 2023-05-05 15:02 UTC (permalink / raw) To: James Bottomley; +Cc: Tom Lendacky, Klaus Kiwi, linux-coco, kvm, amd-sev-snp On Thu, May 04, 2023 at 01:04:09PM -0400, James Bottomley wrote: > Crypto support in ring-0 is unavoidable if we want to retain control of > the VMPCK0 key in ring-0. I can't see us giving it to ring-3 because > that would give up control of the SVSM identity and basically make the > ring-0 separation useless because you can compromise ring-3 and get the > key and then communicate with the PSP as the SVSM. It all depends on what the SVSM allows ring-3 to do, or in other words, how the security model is implemented which locks down the ring-3 services. For example, I can see an attestation service implemented in ring-3 as the exclusive owner of the VMPCK0 key (enforced by SVSM ring-0 code). > I think the above problem also indicates no-one really has a fully > thought out security model that shows practically how ring-3 improves > the security posture. The security model is certainly not fully designed in all details, but when comparing an all-ring-0 (with everything in one address space) approach to a split-code model which moves functionality into separate address spaces and less privileged execution contexts, my bet is that the latter will always win. This is something we know already, so there is no need to re-learn that by evolution. > The next question that's going to arise is *where* the crypto libraries > should reside. Given they're somewhat large, duplicating them for > every cpl-3 application plus cpl-3 seems wasteful, so some type of vdso > model sounds better (and might work instead of a syscall interfaces for > cpl-0 services that are pure code). That, in contrast, is something I would leave to evolution. We can build the services (attestation, TPM, ...) and see if they benefit from a shared-lib for crypto. The dynamic linking for that is certainly not trivial, but can also be fully done in ring-3. > I'm not sure it will be. If some cloud or distro wants to shoot for > FIPS compliance of the SVSM, for instance, a requirement will likely be > to use a FIPS certified crypto library ... and they're all currently in > C. That's not to say we shouldn't aim for minimizing the C > dependencies, but I don't see a "pure rust or else" approach > facilitating the initial utility of the project. Another reason to move all of this to ring-3. Ring-3 services can be written in C and use C libraries as needed without lowering the security of the ring-0 rust code. Regards, -- Jörg Rödel jroedel@suse.de SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2023-05-08 5:17 UTC | newest] Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-03-21 9:29 [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP Jörg Rödel 2023-03-21 11:09 ` James Bottomley 2023-03-21 12:43 ` Jörg Rödel 2023-03-21 13:43 ` James Bottomley 2023-03-21 15:14 ` Jörg Rödel 2023-03-21 17:48 ` Dr. David Alan Gilbert 2023-03-21 18:50 ` Jörg Rödel 2023-03-21 20:05 ` James Bottomley 2023-03-22 1:29 ` Marc Orr 2023-03-22 17:57 ` Daniel P. Berrangé 2023-03-22 9:15 ` Jörg Rödel 2023-03-22 18:07 ` Daniel P. Berrangé 2023-03-22 18:24 ` Dionna Amalie Glaze 2023-03-21 15:06 ` Dr. David Alan Gilbert 2023-03-21 15:25 ` Jörg Rödel 2023-03-21 16:56 ` Dr. David Alan Gilbert 2023-03-21 19:03 ` Jörg Rödel 2023-03-21 19:53 ` Dr. David Alan Gilbert 2023-03-22 9:19 ` Jörg Rödel 2023-03-22 9:43 ` Alexander Graf 2023-03-22 10:34 ` Dr. David Alan Gilbert 2023-03-22 17:37 ` Dionna Amalie Glaze 2023-03-22 17:47 ` Dr. David Alan Gilbert 2023-03-22 21:53 ` James Bottomley 2023-04-11 19:57 ` Tom Lendacky 2023-04-11 20:01 ` Dionna Amalie Glaze 2023-04-13 16:57 ` James Bottomley 2023-04-14 9:00 ` Jörg Rödel 2023-05-02 23:03 ` Tom Lendacky 2023-05-03 12:26 ` Jörg Rödel 2023-05-03 15:24 ` Dionna Amalie Glaze 2023-05-03 15:43 ` James Bottomley 2023-05-03 16:10 ` Daniel P. Berrangé 2023-05-03 16:51 ` Claudio Carvalho 2023-05-03 17:16 ` Alexander Graf 2023-05-05 15:34 ` Jörg Rödel 2023-05-05 15:47 ` Daniel P. Berrangé 2023-05-04 17:04 ` James Bottomley 2023-05-05 12:35 ` Christophe de Dinechin 2023-05-06 12:48 ` James Bottomley 2023-05-08 5:16 ` Alexander Graf 2023-05-05 15:02 ` Jörg Rödel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).