| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-08-19 | |||
| 08:55:59 | gibi | assume | |
| 08:55:59 | sean-k-mooney | so cpu_models = Nehalem is an intel model | |
| 08:56:08 | sean-k-mooney | and it normlaly works on amd | |
| 08:56:16 | sean-k-mooney | but i have seen it not work in some cases | |
| 08:56:36 | sean-k-mooney | have you tested host-model | |
| 08:56:39 | antia | amd has a cpu model with AMD SEV-SNP support (EPYC-v4), but there is none with Intel TDX support | |
| 08:56:45 | gibi | in this case it triggers the feature precondition check without proper image meta passed causing the issue in that bug | |
| 08:58:34 | antia | TDX requires qemu to have -cpu host which is where the requirement for host-passthrough comes from | |
| 08:58:49 | sean-k-mooney | antia: but is that being worked on to fix in qemu | |
| 08:59:10 | sean-k-mooney | antia: its totally fine if that is a limaition in the current qemu | |
| 08:59:28 | sean-k-mooney | but long term that is not somethign we shoudl continue to require | |
| 08:59:58 | sean-k-mooney | we generaly try not ot add feature that do not supprot live migration | |
| 09:00:08 | sean-k-mooney | the excption to that is if its a hardare limiation | |
| 09:00:17 | sean-k-mooney | which this mostly is today | |
| 09:00:26 | sean-k-mooney | (mix of hardare and qemu limiation) | |
| 09:01:36 | sean-k-mooney | as long as there is a path to eventuly supproting live migration with TDX or SEV instance that fine but i woudl hate to force operator to choose between secure vms and 5 9s of uptime for workloads | |
| 09:01:40 | gibi | yeah regardless of the model support live migration is not supported for SEV or TDX | |
| 09:03:20 | sean-k-mooney | gibi: by the way, our current cirros image dont actully supprot uefi boot | |
| 09:03:31 | sean-k-mooney | you can enabel it but the guest wont actully boot | |
| 09:04:11 | sean-k-mooney | qemu/libirt will boot the vm but i think the image just dont have the efi partion requried and the relevent grub config | |
| 09:04:15 | gibi | I use an ubuntu image locally to be able to try attestation as that anyhow needs an extra kernel module in each case | |
| 09:04:27 | sean-k-mooney | ya so on that | |
| 09:04:40 | sean-k-mooney | im kind wish we didnt enable that as part of this feature | |
| 09:04:52 | sean-k-mooney | that really fells like it shoudl have been out of scope | |
| 09:05:09 | gibi | you mean attestation? | |
| 09:05:09 | antia | removing the need for -cpu host was marked as future work, but not sure where it is today | |
| 09:05:10 | antia | removing the need for -cpu host was marked as future work | |
| 09:05:13 | antia | ops | |
| 09:05:17 | antia | https://lists.nongnu.org/archive/html/qemu-devel/2025-04/msg00097.html | |
| 09:05:23 | sean-k-mooney | yes enabel attestation in a portable way is a seprate feature in my view | |
| 09:05:35 | gibi | sean-k-mooney: sure nova does nothing really with attestation | |
| 09:05:37 | sean-k-mooney | so i woudl have wanted that to be its own spec adn have its own extra spec | |
| 09:05:49 | sean-k-mooney | gibi: but we used too | |
| 09:06:03 | sean-k-mooney | we had supprot for opens attstation and trusted boot before | |
| 09:06:04 | gibi | the sev one works out of the box via the cpu itself. the tdx works via a local socket added automatically by libvirt to the guest | |
| 09:06:06 | sean-k-mooney | and we riped it out | |
| 09:06:24 | gibi | so we don't carry any code | |
| 09:06:26 | sean-k-mooney | and we have been asked looks at supprot keylime in the future | |
| 09:06:28 | gibi | and documented nothing | |
| 09:06:42 | gibi | regarding attestation | |
| 09:06:59 | sean-k-mooney | gibi: rgith btu we dotn supprot atested boot today | |
| 09:07:04 | sean-k-mooney | meaning you cant file a bug agasint nova if it does not work | |
| 09:07:13 | antia | this is not attested boot though | |
| 09:07:14 | gibi | sure, that is fine by me :) | |
| 09:07:44 | sean-k-mooney | as long as we dont have to fix bugs related to attestation for tdx im ok with it | |
| 09:08:16 | antia | yeah that is more or less why it was included in the documentation to remove any expectation of Nova doing attestations | |
| 09:08:21 | sean-k-mooney | antia: if the tdx attestation feature is not related to messered secure boot what is it | |
| 09:08:54 | sean-k-mooney | antia: well the docs dont say that its unsuprpoted right. can we just not allcoate teh socket? | |
| 09:09:24 | sean-k-mooney | so that thing we are not testing or cliaming to supprot is not enabled | |
| 09:10:42 | gibi | sean-k-mooney: I would let libvirt do the default that allows anybody who want to try a chance to make it work | |
| 09:11:11 | sean-k-mooney | so i dont htink these type of side channle shoud lbe aviabel to folks to hook up like that | |
| 09:11:28 | sean-k-mooney | like if live migration for exmaple get implemtne only when the socket is not used | |
| 09:11:48 | sean-k-mooney | we woudl not want ot have to chosoe betwen possiebl breakign folks that set it up and making live migration work | |
| 09:11:51 | gibi | we expect that if we use the libvirt default then that will work with future features | |
| 09:12:12 | gibi | what if not having the socket will break the live migration/ | |
| 09:12:15 | gibi | ? | |
| 09:12:34 | gibi | we should not do hypoteticals. Use the underlying default is the safest in my eyes | |
| 09:12:59 | sean-k-mooney | its not that the socket will break it its we are enabling a feature that we dont know the side effect of | |
| 09:13:19 | gibi | we are not enabling it, libvirt does. | |
| 09:13:36 | sean-k-mooney | so we are not addign it to the domain | |
| 09:13:41 | sean-k-mooney | ok | |
| 09:13:59 | gibi | and the whole reason to have these features is to be able to prove that your VM is secure | |
| 09:14:10 | sean-k-mooney | no | |
| 09:14:14 | gibi | so blocking the possibility of that actively is against the goal | |
| 09:14:19 | sean-k-mooney | its to encypt the guest memory | |
| 09:14:31 | sean-k-mooney | proving its secure is its own feature | |
| 09:14:33 | gibi | but how would you know that it is encrypted? | |
| 09:14:37 | antia | encrypting the guest memory is somewhat useless unless it can be proven | |
| 09:14:46 | sean-k-mooney | that is my point attestation of any kind shoudl ahve been its own dedicated feature | |
| 09:15:15 | sean-k-mooney | gibi: im not sure you shoudl knwo that as a normal user or how | |
| 09:15:35 | sean-k-mooney | beyond the flavor extra spec if that is expsoed to you in the releven tcloud | |
| 09:15:50 | gibi | but the premise is that you don't trust the provider so you need a way to be safe | |
| 09:16:04 | gibi | so if the provider tells you it is encrypted you wont trust that either | |
| 09:16:26 | sean-k-mooney | this socket conenct to a deamon run on the host by the provdier | |
| 09:16:31 | sean-k-mooney | you cant trust that eitehr | |
| 09:17:25 | gibi | I guess there are mechanism to make that work. I guess it is just the channel not the source of truth | |
| 09:17:43 | antia | this goes beyond the scope I think. Intel has documentation on this process | |
| 09:18:05 | sean-k-mooney | antia im trying not to second guess the spec | |
| 09:18:16 | gibi | sean-k-mooney: if this helps I'm OK to say in the doc that nova does not actively support attestation. So we can close bugs. But actively preventing attestation I'm not OK with | |
| 09:18:20 | sean-k-mooney | im just highlihgt that i woudl have ask for this to be remvoed if i had reviewed the spec | |
| 09:18:35 | sean-k-mooney | so im highlighting the maintaince concern here not saying we ahve to remove it | |
| 09:18:45 | sean-k-mooney | gibi: yes that woudl help | |
| 09:18:51 | gibi | then lets do that | |
| 09:18:54 | antia | that I can add | |
| 09:19:04 | gibi | thanks both of you | |
| 09:19:34 | sean-k-mooney | gibi: im just sentitve to the fact that folks have come to depend on the internals of some feature that we didnt intnet to be public in the past | |
| 09:19:55 | sean-k-mooney | i.e. cloud-init incorrectly usign our dmi/smbios code to detech that its oepnstack | |
| 09:20:02 | gibi | I think in case of AMD you cannot even prevent attestation from libvirt if encryption is on | |
| 09:20:09 | sean-k-mooney | even though that only ever worked for libvirt | |
| 09:20:43 | sean-k-mooney | ack | |
| 09:21:17 | sean-k-mooney | antia: for what its woth the feature more or less looks ok | |
| 09:21:35 | sean-k-mooney | the main blocker for me is you missing the libvirt version check and the cgroups issue i mentioned in teh review | |
| 09:21:51 | antia | thanks for reviewing! | |
| 09:21:58 | sean-k-mooney | antia: once those 2 issues are adressed i think we can more or less proceed with the series | |
| 09:22:00 | antia | the cgroup issue I am resolving right now | |
| 09:22:26 | sean-k-mooney | cool | |
| 09:23:32 | gibi | sean-k-mooney: about the version check | |
| 09:23:34 | antia | I am not strictly against a version check for TDX, but I find it unnecessary. The same isn't done for SNP and it is not needed since Libvirt capabilities can handle it | |
| 09:23:41 | gibi | yeah ^^ | |
| 09:24:07 | gibi | so libvirt only reports the domcap if libvirt + qemu is supporting the feature | |