| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-07-06 | |||
| 16:20:16 | sean-k-mooney | and 2 we woudl need a config option in nova | |
| 16:20:31 | sean-k-mooney | it repots | |
| 16:20:33 | sean-k-mooney | <launchSecurity supported='yes'> | |
| 16:20:35 | sean-k-mooney | <enum name='sectype'> | |
| 16:20:37 | sean-k-mooney | <value>sev</value> | |
| 16:20:39 | sean-k-mooney | <value>sev-snp</value> | |
| 16:20:41 | sean-k-mooney | </enum> | |
| 16:20:43 | sean-k-mooney | </launchSecurity> | |
| 16:20:50 | sean-k-mooney | <value>sev-snp</value> should not be there if the host is not configure for snp | |
| 16:21:24 | tkajinam | the tricky point is that we should catch the case that sev-snp is enabled in firmware, but is not in kernel/qemu/libvirt | |
| 16:21:38 | sean-k-mooney | not in nova | |
| 16:21:43 | tkajinam | because enabling sev-snp in firmware immediately prohibits sev-es | |
| 16:21:51 | sean-k-mooney | that is what libvirt is ment to be doing with that api | |
| 16:21:54 | gibi | (I like the CVE :) | |
| 16:21:54 | tkajinam | but kernel still reports sev_es is available which is annoying | |
| 16:22:10 | sean-k-mooney | sure but libvirt does not | |
| 16:22:20 | bauzas | fwiw we discussed that in the spec | |
| 16:22:26 | sean-k-mooney | well it reqport generic sev which i guess we might be proxiting | |
| 16:22:41 | sean-k-mooney | bauzas: we have rejected parsinc /proc before | |
| 16:22:46 | sean-k-mooney | so i dont knwo why we woudl allow it now | |
| 16:23:02 | bauzas | we said that the BIOS option is the difference between whether we support SNP or ES | |
| 16:23:26 | bauzas | so, if the operator modified the bios option, then the system supports SNP and that's it | |
| 16:23:49 | sean-k-mooney | ok so then nova does not need to check for this right | |
| 16:23:52 | bauzas | correct | |
| 16:24:03 | bauzas | that's what we agreed on the spec at least | |
| 16:24:28 | sean-k-mooney | so if livbirt has sev-snp in the lauch capabliteis | |
| 16:24:34 | sean-k-mooney | we should just report the trait | |
| 16:24:39 | bauzas | we don't need to look at the firmware, because even if the firmware can support SNP, the host won't use this until the BIOS is modified | |
| 16:24:45 | sean-k-mooney | and if the operator has not enabeld snp but did create snp flavors | |
| 16:24:52 | sean-k-mooney | then we expect the vm boot to fail | |
| 16:25:13 | gibi | it is about the fact the ES support disappears after that specific firmware upgrade and you can still have ES VMs on thehost | |
| 16:25:19 | bauzas | libvirt provides SNP capabilities only once the BIOS option is modified | |
| 16:25:35 | gibi | the complication is not about SNP, but the disappearence of ES | |
| 16:25:50 | sean-k-mooney | bauzas: ack in that case then we jsut need to look at the libvirt output | |
| 16:25:53 | bauzas | gibi: AFAICU, the ES support continues until the BIOS option is modified, that's my point | |
| 16:26:10 | bauzas | tkajinam: am I right? | |
| 16:26:16 | gibi | if you had a host with both ES and SNP enabled, and then update the firmware, ES disappears without BIOS changes | |
| 16:26:31 | gibi | * BIOS config changes | |
| 16:26:33 | bauzas | because you enabled SNP | |
| 16:26:34 | tkajinam | bauzas, the problem is that /proc/cpuinfo is only the feasible way I could find to detect "the BIOS option is modified" | |
| 16:26:42 | sean-k-mooney | well the sev section has | |
| 16:26:44 | sean-k-mooney | <sev supported='yes'> | |
| 16:26:46 | sean-k-mooney | <cbitpos>51</cbitpos> | |
| 16:26:47 | gibi | bauzas: because you updated the firmware to fix a CVE | |
| 16:26:48 | sean-k-mooney | <reducedPhysBits>1</reducedPhysBits> | |
| 16:26:50 | sean-k-mooney | <maxGuests>500</maxGuests> | |
| 16:26:52 | sean-k-mooney | <maxESGuests>9</maxESGuests> | |
| 16:26:54 | sean-k-mooney | <cpu0Id>LlF/9YPV8hnqsGNCBpLJeRUbm9y/yr5uNhgTaW96/ZVoYXjZRRuIfEwSMFWWd9882pcNDLW6LW3E3tytpU7/2g==</cpu0Id> | |
| 16:26:56 | sean-k-mooney | </sev> | |
| 16:26:59 | sean-k-mooney | the max es gust is still reproted in snp mode | |
| 16:27:17 | sean-k-mooney | but i think we need to look at the combidntion fo the lauchsecurit section and the sev section | |
| 16:27:18 | gibi | beacuse the same set of ASIDs are used for ES and SNP | |
| 16:27:33 | gibi | but a different set used for pure SEV | |
| 16:28:07 | bauzas | gibi: well, that's another concern, if the operator enabled SNP in the BIOS and then upgraded the firmware due to the CVE, they should know that ES is then disabled automatically | |
| 16:28:07 | gibi | btw that CVE fix is actually good for us as we don't have to share resources between ES and SNP | |
| 16:28:20 | gibi | bauzas: | |
| 16:28:37 | bauzas | that's unrelated to nova, right? | |
| 16:28:45 | gibi | but nova has ES VMs on the host :): | |
| 16:28:50 | gibi | so we cannot ignore it | |
| 16:29:11 | tkajinam | bauzas, yes and that's why /proc/cpuflag is checked, because at that point sev-snp is not yet enabled in kvm ( so nova assumes sev-snp is not ready ) | |
| 16:29:15 | bauzas | I think I wrote a spec comment saying about when we restart the compute | |
| 16:29:26 | sean-k-mooney | gibi: do you happen to know if the host you are testing on has the firmware patch | |
| 16:29:38 | bauzas | we can look at the instances and stop the service if we find ES-used instances | |
| 16:29:48 | gibi | it has. It is not possible to boot ES VMs on it | |
| 16:29:51 | gibi | qemu fails | |
| 16:30:01 | tkajinam | https://review.opendev.org/c/openstack/nova/+/994343 | |
| 16:30:08 | sean-k-mooney | ok and does it work with snp disabled | |
| 16:30:10 | tkajinam | this is the actual change where this is being discussed | |
| 16:30:16 | gibi | sean-k-mooney: I don't know that | |
| 16:30:21 | sean-k-mooney | i dont think this is an upgrede concern for nova yet | |
| 16:30:35 | sean-k-mooney | since nova didnt supprot snp before this firmware change | |
| 16:30:43 | gibi | but it did support ES | |
| 16:30:45 | sean-k-mooney | so we just need to document that operator can use oen of the other | |
| 16:30:55 | sean-k-mooney | gibi: right if they flat out broke es with the cve fix | |
| 16:31:03 | tkajinam | so reading actual implementation may give clearer view about the topic. | |
| 16:31:15 | sean-k-mooney | that woudl be a problem but if it works just not when snp is enabeld in teh bios its not an upgrade probvlem | |
| 16:31:20 | gibi | they actaully disabled ES on purpose as when SNP is enabled ES becomes voulnerable | |
| 16:31:31 | bauzas | https://review.opendev.org/c/openstack/nova-specs/+/983376/20..21/specs/2026.2/approved/amd-sev-snp-libvirt-support.rst#b62 | |
| 16:31:37 | sean-k-mooney | sure but as long as you can choose between the two its fine | |
| 16:31:50 | bauzas | so the concern is that we need to look at /proc/cpuinfo ? | |
| 16:31:58 | sean-k-mooney | from a nova point of view we just need to docuemnt that es and snp are mutally exclisive | |
| 16:32:04 | sean-k-mooney | bauzas: yep | |
| 16:32:22 | sean-k-mooney | bauzas: i dont think bypsassing libvirt to look at /proc/cpuinfo is ok | |
| 16:32:31 | bauzas | and there are no other ways to detect a SNP-supported OS ? | |
| 16:32:48 | sean-k-mooney | bauzas: i think that is reported in the launchSecurity section | |
| 16:33:01 | sean-k-mooney | but we woudl have to disabel snp in the bios to confirm | |
| 16:33:07 | bauzas | yeah | |
| 16:33:07 | sean-k-mooney | and im hesitent to ask gibi to do that | |
| 16:33:12 | tkajinam | sean-k-mooney, no launchSecurity does not fully match with sev_snp cpu flag | |
| 16:33:26 | gibi | we agreed in the spec that if we have ES VMs on a host the nova-compute is restarted and sees that no ES capability is available any more due to SNP enabled then nova-compute will fail to start and let the deployer know that there is a mixup of configuration and ask for draining the ES VMs before enabling SNP | |
| 16:33:27 | sean-k-mooney | so its list there whewn its disabeld in the bios | |
| 16:33:28 | tkajinam | sean-k-mooney, for example if you are using an older libvirt then it doesn't have that option but you can enable snp in firmware | |
| 16:33:29 | sean-k-mooney | ? | |
| 16:33:40 | sean-k-mooney | tkajinam: that fine | |
| 16:33:49 | sean-k-mooney | old libivrt is handled by a min version check | |
| 16:33:54 | tkajinam | but that still disables sev-es | |
| 16:34:10 | tkajinam | in hardware level | |
| 16:34:11 | sean-k-mooney | gibi: yep that is the corect behvior | |
| 16:34:40 | sean-k-mooney | its not enfocning that that i object too | |
| 16:35:01 | sean-k-mooney | its how we are determinign that that is problematic | |