| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-08-19 | |||
| 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 | |
| 09:24:25 | sean-k-mooney | oh we already have that supproted via domcaps | |
| 09:24:29 | gibi | yeah | |
| 09:24:34 | sean-k-mooney | and we are usign that to fileter the traits reporitng | |
| 09:24:38 | gibi | the flag yes, the capacity does not | |
| 09:24:39 | sean-k-mooney | ok then jsut the cgroups issue | |
| 09:24:50 | gibi | yepp | |
| 09:24:54 | antia | okay good | |
| 09:24:57 | sean-k-mooney | sorry i missed that | |
| 09:25:37 | gibi | no worries | |
| 09:40:24 | gibi | so about scsi. On my machine the VM is created successfully but cannot boot. It stops at the EFI setup not seeing a boot device | |
| 09:56:28 | antia | that is consistent with my previous experience | |
| 10:27:15 | sean-k-mooney | that is becaus of the qemu firmware image yes? | |
| 10:27:25 | sean-k-mooney | so it may or may not work dependin on that | |
| 10:27:41 | sean-k-mooney | im not sure if we shoudl relaly block it in nova but we shoudl call it out in the docs | |
| 10:39:43 | gibi | yepp call it out in the doc | |
| 10:40:06 | gibi | (and yes I tested without TDX that the same image boots from scsi) | |
| 10:40:58 | sean-k-mooney | ack, i partly wonder if we are jsut mising setting somethign liek the iommu options we recnelty stop setting for sev | |
| 10:41:15 | sean-k-mooney | but i guess we can follow up with improvment next cycle if we discover a way to supprot it | |
| 10:41:22 | sean-k-mooney | and jsut treat it as a minor bugfix | |
| 10:41:41 | gibi | OK | |
| 11:16:23 | opendevreview | Bhavana proposed openstack/nova-specs master: Add spec for MIG-aware PCI Host Weigher https://review.opendev.org/c/openstack/nova-specs/+/998753 | |
| 11:52:49 | sean-k-mooney | im generally not sure ^ is something that is really in nova scope now | |
| 11:53:20 | sean-k-mooney | cybrog will need a way to provide its own way to experss schdulign prioties in the future | |