| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-04-10 | |||
| 15:17:07 | tkajinam | kashyap, thanks ! | |
| 15:17:13 | kashyap | It looks like, we won't get to that topic today. So let's keep the discussion on the Etherpad / spec :-) | |
| 15:17:51 | kashyap | tkajinam: A year ago or so, I've spent some time testing SEV-SNP. I need to refresh on it, though. I'll do some more analysis on where are various low-level projects on it, and get back | |
| 15:18:18 | tkajinam | (I'll post the same comments in etherpad and spec but) I agree that we should be careful about the investment. tbvh this work to support SEV-ES is more like a practice of extending the current implementation so that we can quickly work on SEV-SNP | |
| 15:19:26 | tkajinam | once the whole implementations are merged in upstream | |
| 15:22:25 | kashyap | Yeah, I see your point, but we shouldn't go deep into ES-specific impl details in Nova. | |
| 15:25:19 | tkajinam | We have already built PoC with patched kernel/qemu/libvirt/openstack to test SEV-SNP and the proposal is based on the learning in that work. the items specific to SEV-ES is the detection of ES capability and additional policy flag bit in libvirt and the other parts will be reused by SEV-SNP | |
| 15:28:36 | bauzas | tkajinam: Extending memory encryption support is planned at 1545UTC | |
| 15:28:54 | bauzas | now this is break time | |
| 15:29:00 | tkajinam | bauzas, ack. thanks | |
| 15:30:24 | dansmith | melwitt: the glance encryption thing will be in the cinder room, fyi | |
| 15:30:42 | melwitt | dansmith: ah ok, thanks | |
| 15:31:12 | dansmith | melwitt: nowish | |
| 15:31:19 | melwitt | oh, k | |
| 15:31:24 | dansmith | if you can | |
| 17:15:06 | bauzas | tobias-urdin: oh shit, just saw you weren't available neither today or tomorrow :( | |
| 17:15:26 | bauzas | any possibility tho to join us for only one hour ? | |
| 17:15:41 | bauzas | I can arrange ourselves on a specific time for you | |
| 17:17:14 | bauzas | stephenfin: are you okay discussing your topic tomorrow ? | |
| 17:18:55 | kashyap | bauzas: I missed the 17:45 slot :( But I added my thoughts in the Etherpad and the spec | |
| 17:19:04 | bauzas | np | |
| 17:21:14 | kashyap | tkajinam: Okay, we can talk more tomm. So you've also been testing SNP based on upstream on-list patches? I'm not sure who you mean by "we" :) | |
| 17:22:06 | tkajinam | kashyap, sure | |
| 17:24:11 | tkajinam | kashyap, I'm now part of a small team here in NTT DATA(my current employer), we have been using kernel/qemu/ovmf maintained in https://github.com/AMDESE (I think these contain patches proposed in lists) with libvirt and OpenStack additionally patched. | |
| 17:26:17 | kashyap | tkajinam: Ah, I see. Nice. I work w/ some of the confidential computing folks at RHT. Although, I'm not up2date on this area now, I poked some the SEV-SNP stuff w/ `sevtool`, etc back on Oct 2022. | |
| 17:27:14 | tkajinam | We've built a small PoC system which provides VM with its memory and disk encrypted and protected from hosts. Because we wanted some mechanism to detect any tampered bootchain elements(like kernel with any backdoor installed) we decided to use SEV-SNP which was most heading last year. I saw some works have done recently by Intel and am planning to try Intel TDX this year as well. | |
| 17:27:15 | kashyap | s/back on/back in/ | |
| 17:28:22 | kashyap | tkajinam: I see, nice. Do you also care about the whole attestation / measured boot thing? (I'm guessing you do) | |
| 17:28:34 | tkajinam | kashyap, yeah, I read their articles actually during my on-boarding process. | |
| 17:29:11 | kashyap | tkajinam: Nice. Shameless plug, I once wrote this too, but I'm a bit out-of-date now :D - https://lwn.net/Articles/838488/ | |
| 17:29:56 | kashyap | Some of the tools mentioned at the end got deprecated, or new tools came in. And the "remote attestation" problem noted there is still a bit of a "beast" upstream, w/ various vendors coming up with their schemes. | |
| 17:30:15 | kashyap | tkajinam: Consolidating on one approach to remote attestation seems to be a multi-year effort. | |
| 17:30:22 | tkajinam | kashyap, yeah. we built a PoC which releases disk encryption key based on successful remote attestation, which uses attestation reports containing boot chain measurement. | |
| 17:31:13 | tkajinam | kashyap, yeah but an interesting point is that hyperscalers already created their own services. that's why we are looking into it | |
| 17:32:06 | tkajinam | one of our current main strategies, after we finished PoC, is to make sure we work closely with upstream and contribute anything we can. that's why I'm starting some work in nova and would probably spend some time in lower layers such as libvirt | |
| 17:32:48 | kashyap | tkajinam: Huh, I see. So you have your own remote-attestation mechanism too? :) | |
| 17:33:23 | kashyap | tkajinam: Do you use tools like 'sev-snp-measure'? | |
| 17:33:53 | kashyap | tkajinam: I see, fair enough. Hyperscalars will come around once the dust settles upstream, I guess | |
| 17:35:08 | tkajinam | I use sev-snp-measure or a few other tools for testing but mainly we built remote attestation api, which is created from the one maintained in https://github.com/confidential-containers/trustee | |
| 17:35:08 | kashyap | tkajinam: Good to hear! BTW, I also saw your mail on the upstream 'libvirt-devel' list about exposing SEV-ES via the new 'model' element | |
| 17:35:36 | tkajinam | yeah. that's one of the "practices" I'm doing for the overall work | |
| 17:36:31 | tkajinam | kashyap, In our PoC we inject a script into geust which reads attestation report and send it to that remote attestation api, and then remote attestation api returns disk encryption key only when it can verify the report. | |
| 17:36:33 | kashyap | Okay, good to know that your aim is to work with the relevant upstreams. As you know, there are many moving parts here: kernel, OVMF, QEMU, libvirt, and Nova. | |
| 17:36:48 | tkajinam | yeah | |
| 17:37:54 | tkajinam | honestly speaking I'm not much familiar with the lower level things like kernel or even qemu, but am hoping that I can work on more control-plane layers like libvirt or nova because resource coordination is one of the topics for which I've been working for some time. | |
| 17:39:58 | kashyap | tkajinam: Okay, cool. One last thing before I go out: on your libvirt thing: I saw DanPB's response on using "maxESGuests" to detect number of SEV-ES availability. I also saw your response; let's see what the other maintainers say there. | |
| 17:40:45 | tkajinam | kashyap, thanks! I was wondering if I made something wrong which caused no response for some time but probably people are just busy | |
| 17:40:45 | kashyap | tkajinam: I'm also not an expert on those; but I work w/ KVM/QEMU/libvirt devs on other areas, so I can ping the "right person" if nedeed on an upstream thread | |
| 17:41:25 | kashyap | tkajinam: No, you didn't do anything wrong. Dan Berrange seems to be away for a few days. | |
| 17:41:32 | tkajinam | good to hear :-) | |
| 17:41:33 | kashyap | tkajinam: I can ping him once he's back; I don't see him around. | |
| 17:42:20 | tkajinam | kashyap, it'd be nice if I can have some conversations with Red Hat people working in this area, to discuss plans in both sides (if possible and interesting). I also find recent working about TDX in CentOS quite interesting and was willing to have some conversation about its status and future plan. | |
| 17:42:26 | kashyap | tkajinam: I saw your v2; don't hesitate to send a "3rd ping" on the list after a few more days. That's how it works on that list sometimes. | |
| 17:42:37 | tkajinam | kashyap, ack. will do ! | |
| 17:42:39 | kashyap | tkajinam: Sure, you can join #virt on OFTC. | |
| 17:42:53 | kashyap | tkajinam: And the SEV measurement folks hang out on Matrix, #virtee: https://virtee.io/ | |
| 17:43:12 | kashyap | I need to step out now; back later :) | |
| 17:43:17 | tkajinam | ok. yeah I know VirTEE but haven't looked into its communication channel. will check it ! | |
| 17:43:32 | tkajinam | kashyap, thanks. I'm stepping away too now. Have a good day ahead :-) | |
| 18:23:59 | opendevreview | Mark Goddard proposed openstack/nova master: Support creating servers with RBAC SGs https://review.opendev.org/c/openstack/nova/+/811521 | |
| 20:52:38 | tkajinam | zigo, hmm. it seems the problem is a bit more tricky in debian and ubuntu. | |
| 20:53:48 | tkajinam | xorriso package in CentOS provides the simple mkisofs command. IIUC this is a wrapper internally calls 'xorriso -as mkisofs' | |
| 20:56:49 | tkajinam | because current nova doesn't allow adding additional options we need such single command replacing genisoimage. probably is the xorrisofs command the one ? | |
| 20:58:44 | tkajinam | the package in CentOS provides xorriso, too, it seems, so probably switching to it is the wise option | |
| 20:58:58 | tkajinam | I thought I saw a patch to update the default but I could not find it for some reason. | |
| #openstack-nova - 2024-04-11 | |||
| 08:41:07 | stephenfin | bauzas: Sorry, was out sick yesterday. I can talk about that today. What time? | |
| 08:42:46 | bauzas | stephenfin: we start at 1pm UTC by tkajinam's topic so probably around 1.30pm UTC | |
| 08:43:24 | bauzas | https://etherpad.opendev.org/p/nova-dalmatian-ptg#L538 | |
| 08:45:09 | bauzas | actually, a bit later, I added some related topics for live-migration before your topic | |
| 08:45:51 | bauzas | stephenfin: also gmann wanted to be on your session, so would you be okay to be around 3pm UTC or a bit later ? | |
| 08:46:17 | stephenfin | 3pm UTC or thereabouts is fine by me | |
| 08:46:23 | stephenfin | bauzas: ^ | |
| 08:46:29 | bauzas | ++ | |
| 08:46:31 | bauzas | thanks | |
| 09:51:29 | sean-k-mooney | ill need to drop early today but bauzas can you ping when the ptg is starting and ill try to join on time today | |
| 10:06:58 | bauzas | sean-k-mooney: as it's said in the agenda, 1300UTC | |
| 10:07:26 | sean-k-mooney | yes i know i just often get pulled into meeting which is why i was late the last two days | |
| 10:07:37 | sean-k-mooney | if you can just ping the channeal and say hay ptg is starting ill see it | |
| 10:12:56 | opendevreview | Stephen Finucane proposed openstack/nova-specs master: Add openapi spec https://review.opendev.org/c/openstack/nova-specs/+/909448 | |
| 10:25:05 | stephenfin | bauzas: when you've a chance, can you explain what you meant here so I can close it off? https://review.opendev.org/c/openstack/nova-specs/+/909448/6/specs/2024.2/approved/openapi.rst#277 | |
| 10:26:34 | stephenfin | bauzas: sean-k-mooney: I have a 30 patch series adding all the missing request body/query string schemas and maybe 50% of the response body schemas. How much, if any, of that do you want me to push ahead of the discussion later today? | |
| 10:27:06 | sean-k-mooney | you might as well push it all | |
| 10:27:21 | sean-k-mooney | well or save the gate till later | |
| 10:27:33 | sean-k-mooney | push at least the first 1 or 2 so we can see what it looks like | |
| 10:28:12 | sean-k-mooney | if you want to save the gate create a github fork and just push the branch and link it to the disucssion | |
| 10:28:41 | sean-k-mooney | but if you have done thw work you might as well put it up | |
| 11:18:23 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Followup to I2ed738f87fed952f60849cc22bde7291ec52d286 https://review.opendev.org/c/openstack/nova/+/915474 | |
| 11:46:15 | opendevreview | Merged openstack/nova stable/2023.1: pwr mgmt: handle live migrations correctly https://review.opendev.org/c/openstack/nova/+/913227 | |
| 12:33:42 | kashyap | Is it a break now? I don't see anyone on the call for the stateless firmware discussion | |
| 12:34:57 | sean-k-mooney | it does not start for 30 mins | |
| 12:35:05 | kashyap | Ah, silly me. | |
| 12:59:31 | SvenKieske | sean-k-mooney: ping ;) | |
| 13:04:20 | gibi | elodilles: thanks for helping me landing the powermgmt fix backports, it is done now | |
| 13:04:33 | gibi | artom: ^^ | |
| 13:26:08 | artom | gibi, yep, many thanks! | |
| 13:26:32 | artom | We just need https://review.opendev.org/c/openstack/nova/+/915139/3 to make whitebox work correctly now | |
| 13:27:40 | artom | (It's that NUMA/non-NUMA collocation issue - technically not supported, but whitebox uses it for CI reasons, so it needs live migration with cpu_shared_set to work correctly) | |
| 13:28:29 | bauzas | tobias-urdin: I saw you were not able to join us today but we start discussing your topic | |
| 13:28:47 | bauzas | we'll try to provide as much information in the etherpad as possible | |
| 13:40:56 | gmann | bauzas: 3pm UTC or anytime before 4 PM UTC(TC discussions start) is ok for me | |