| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-08-19 | |||
| 08:51:01 | sean-k-mooney | so if future qemu cpu models supprot tdx | |
| 08:51:15 | sean-k-mooney | then we dont want the extra code in nova to filter the triats | |
| 08:51:42 | opendevreview | Lajos Katona proposed openstack/nova master: libvirt: Preserve queue_size during live migration https://review.opendev.org/c/openstack/nova/+/995841 | |
| 08:51:49 | sean-k-mooney | taht why i didnt suggest that in the review but ya it makes me a bit uneasy | |
| 08:53:51 | gibi | I'm not sure that host-passthrough requirement is valid on cpu level or just a consequence of this bug https://bugs.launchpad.net/nova/+bug/2158927/comments/1 | |
| 08:54:37 | gibi | antia: ^^ could you confirm which is the case? | |
| 08:55:21 | gibi | sean-k-mooney: antia: fyi I'm on PTO Thru/Fri this week but I'm back on Monday | |
| 08:55:33 | sean-k-mooney | gibi: ack | |
| 08:55:57 | gibi | we have FF next Thursdays I assuem | |
| 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 | |