| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-25 | |||
| 13:55:53 | aspiers | efried: that might be possible. when is it? | |
| 13:55:57 | efried | ... | |
| 13:55:58 | sean-k-mooney | actuly i think these might be auto generated form teh metadefs | |
| 13:56:01 | mriedem | stephenfin: https://docs.openstack.org/glance/latest/admin/manage-images.html | |
| 13:56:07 | mriedem | sean-k-mooney: they are not | |
| 13:56:15 | mriedem | the useful-image-properties page is hand-written | |
| 13:56:26 | efried | aspiers: https://www.openstack.org/summit/denver-2019/summit-schedule/events/23620/nova-project-onboarding | |
| 13:56:40 | sean-k-mooney | oh ok ill update them so. thanks for the pointer | |
| 13:56:48 | kashyap | edleafe: On that traits patch, please see if I've answered your question | |
| 13:56:52 | mriedem | lyarwood: if you fix the alignment here https://review.opendev.org/#/c/655696/1/nova/virt/libvirt/driver.py i'm +2 | |
| 13:57:21 | kashyap | edleafe: Ah, you've actually responded; I just needed to refresh it | |
| 13:57:36 | edleafe | kashyap: damn, I'm fast! | |
| 13:58:14 | kashyap | Damn, what I thought was a drive-by is becoming a shaving a farm of yaks :D | |
| 13:58:21 | efried | kashyap: I was going to respond on that one too, with a summary. TLDR, what I said in my last response, do that split and "deprecate" the HW_CPU_AMD_SEV in favor of HW_CPU_X86_AMD_SEV | |
| 13:59:13 | kashyap | efried: By "deprecate", you mean just add a note that it's bogus, right? | |
| 13:59:46 | efried | yes | |
| 13:59:48 | sean-k-mooney | efried: just re reviews kashyap cpu selection spec and im fine with the new verions. thanks kashyap | |
| 13:59:59 | kashyap | sean-k-mooney: Thanks! | |
| 14:00:03 | edleafe | Yeah, since the trait won't ever be removed. More of a "we screwed up; don't use this one" note | |
| 14:00:21 | kashyap | sean-k-mooney: We'll get to debate fun details in the implementation :D I have a WIP post patch to introduce the infra, before it gets lost | |
| 14:00:39 | efried | kashyap: re edleafe's comment on the NO_SSB thing, I thought that wasn't so much a negative trait as advertising that "this CPU has had the horrible thing removed". | |
| 14:00:54 | efried | iow, absent that trait, you can't tell whether it's there or not | |
| 14:01:13 | efried | so we want that trait so the consumer can be sure the horrible thing is gone. | |
| 14:01:19 | kashyap | Exactly | |
| 14:01:24 | edleafe | efried: if that's the case, then rename it to a positive assertion of a capability | |
| 14:01:29 | kashyap | That's why I wanted to mention it. Let me read Ed's comment | |
| 14:01:35 | efried | edleafe: like SSB_REMOVED? | |
| 14:01:47 | edleafe | sure, something along those lines | |
| 14:01:51 | efried | edleafe: Would prefer to retain symmetry with the CPU traits themselves, though. | |
| 14:02:07 | kashyap | "NO_SSB" == No more SSB vulnerability on this host CPU -- isn't that clear enough? | |
| 14:02:08 | sean-k-mooney | kashyap: i would like to see two thing. 1 on sucessful validation print the cpu configurtion the guest will see as an info long. on failure pritn the requested combination, whant the host supports and what could not be supproted as an error log. | |
| 14:02:09 | efried | with the names from the architecture, that is | |
| 14:02:31 | efried | kashyap: IMO it is, and is preferable to renaming it to make it sound more positive | |
| 14:02:39 | efried | just need to get edleafe on board with that | |
| 14:02:59 | kashyap | Okay, I'll go re-read the comments. These flags have some dizzying acronyms | |
| 14:03:12 | sean-k-mooney | kashyap: im not sure we should be tracking vulnerblities as traits | |
| 14:03:29 | edleafe | efried: not having something isn't a capabilty. Being clean of some defect is. | |
| 14:03:29 | kashyap | sean-k-mooney: Huh, we're not | |
| 14:03:32 | stephenfin | sean-k-mooney: What happens if this isn't true? https://review.opendev.org/#/c/629589/27/nova/virt/libvirt/driver.py@8161 | |
| 14:03:37 | efried | edleafe: These are going to be consumed by people who are familiar with the arch and are looking for the equivalent trait, not people who are just casting around and trying to understand a trait based on its name. | |
| 14:03:47 | sean-k-mooney | NO_SSB kind of is | |
| 14:03:49 | kashyap | sean-k-mooney: It's a CPU flag. Please ask before you assume :-) | |
| 14:04:02 | sean-k-mooney | i know what it is | |
| 14:04:05 | sean-k-mooney | i was not assuming | |
| 14:04:17 | kashyap | Well, it's a CPU flag. We need to track it as a "trait", if you want to report that a given Compute host is no more vulnerable to it | |
| 14:04:25 | kashyap | Is something wrong with t? | |
| 14:04:28 | kashyap | s/t/it/ | |
| 14:04:50 | edleafe | kashyap: is it generally referred to as NO_SSB in the relevant documentation (asking because I have no idea) | |
| 14:04:58 | sean-k-mooney | if we have NO_SSB i can do traits:no_SSB=forbiden and then deploy a workload that expliot it to a host that has the vulnerablity | |
| 14:05:03 | kashyap | edleafe: Exactly what efried said. These are for admins who read their documentation (and they will be sufficiently rewarded) | |
| 14:05:11 | efried | edleafe: https://git.qemu.org/?p=qemu.git;a=blob;f=docs/qemu-cpu-models.texi#l313 | |
| 14:06:09 | mriedem | tssurya: fyi in case you haven't seen this https://review.opendev.org/#/c/636947/ | |
| 14:06:22 | efried | edleafe: This set of traits is being mapped directly from that document | |
| 14:06:25 | mriedem | bauzas: ^ is a nice little perf improvement when listing AZs in a large cloud | |
| 14:06:38 | edleafe | efried: ok, I understand a bit more. | |
| 14:06:43 | bauzas | mriedem: okay | |
| 14:06:46 | efried | edleafe: sections important_cpu_features_intel_x86 and important_cpu_features_amd_x86 | |
| 14:06:49 | tssurya | mriedem: yeah I have it open | |
| 14:06:59 | bauzas | mriedem: FWIW, I'll be traveling starting tonight | |
| 14:07:02 | tssurya | thanks for doing that | |
| 14:07:08 | edleafe | That doc also defines things such as mutually exclusive traits, which os-traits and placement doesn't enforce | |
| 14:07:34 | sean-k-mooney | efried: edleafe i still think we need to consider the securtiy impact of having NO_SSB as a trait before we add it | |
| 14:07:35 | efried | edleafe: true story, but not really relevant; the driver is going to detect what's on the CPU and report that. | |
| 14:07:36 | mriedem | tssurya: thank avolkov | |
| 14:07:56 | kashyap | edleafe: Only 'amd-no-ssb | |
| 14:08:08 | kashyap | edleafe: Only 'amd-no-ssb' is the mutually exclusive trait. | |
| 14:08:29 | kashyap | Again, what efried said ^ (on driver detecting) | |
| 14:08:36 | edleafe | sean-k-mooney: what would the potential impact be? A CPU reporting it that is actually vulnerable to it? | |
| 14:08:45 | sean-k-mooney | yes | |
| 14:08:46 | tssurya | I tweaked a downstream patch when we opened that bug, never got around to doing it upstream | |
| 14:09:00 | sean-k-mooney | and then a user uploading an image that require a cpu with the vulnerablity | |
| 14:09:01 | efried | edleafe: sean-k-mooney is saying a malicious user could specify NO_SSB as a forbidden trait to deliberately land on a vulnerable host. | |
| 14:09:02 | kashyap | sean-k-mooney: Also what is "forbidden" in this context? | |
| 14:09:19 | efried | kashyap: We have the ability to specify a request with "DON'T land on a host if it has this trait" | |
| 14:09:23 | sean-k-mooney | kashyap: we support requireing traitns or selecting host that do not have a trait | |
| 14:09:28 | kashyap | efried: Ah-ha | |
| 14:09:44 | efried | kashyap: The placement request would look like required=!HW_CPU_X86_AMD_NO_SSB | |
| 14:09:47 | sean-k-mooney | so if we report either the presence or absence of ssbd | |
| 14:10:01 | efried | kashyap: From a flavor extra spec like trait:HW_CPU_X86_AMD_NO_SSB=forbidden IIRC | |
| 14:10:20 | sean-k-mooney | i can exploit that to target a host with the volnerablity with my payload | |
| 14:10:28 | efried | Yeah, I don't know if this is a problem though sean-k-mooney | |
| 14:10:29 | kashyap | Yeah, noted. | |
| 14:10:41 | edleafe | sean-k-mooney: so without that trait, attackers could just spin up random VMs and see if they are on a vulnerable host. Having the trait just makes those hosts easier to find. Is that it? | |
| 14:10:49 | kashyap | efried: Yeah, that's what I was wondering. The positives of having it outweigh some theoretical threat | |
| 14:10:51 | efried | The admin is responsible for putting together the flavors. Why would the admin do that? | |
| 14:10:56 | sean-k-mooney | edleafe: yes | |
| 14:11:18 | sean-k-mooney | i would like the openstack security team to weigh in on this personally | |
| 14:11:37 | efried | there's an email address for that, right? | |
| 14:11:46 | mriedem | efried: gibi: trying to recreate this TestRPC infinite recursion is getting frustrating :) https://review.opendev.org/#/c/654468/ - i'm thinking maybe push another change to oslo.config (or nova?) that sets the max recursion depth and see if that blows things up? | |
| 14:11:47 | sean-k-mooney | efried: users can upload image with traits request | |
| 14:11:59 | sean-k-mooney | so its not admin im worried about | |
| 14:12:00 | kashyap | efried: Yes, very good point on admin's responsibility | |
| 14:12:28 | efried | http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security | |
| 14:12:32 | gibi | mriedem: I also tried to reproduce it locally without success. Do you assume that if you set the recursion limit to small enough then the stack trace will not be truncated? | |
| 14:12:44 | efried | ugh, do you have to be subscribed to post to that? | |
| 14:13:00 | kashyap | efried: Not necessarily | |
| 14:13:05 | sean-k-mooney | efried: there is but we can also talk to them in person next week | |
| 14:13:09 | kashyap | efried: Mailman moderator can approve you | |
| 14:13:14 | sean-k-mooney | we will all be in the same place | |
| 14:13:29 | kashyap | sean-k-mooney: In-person, things get too long-winded, and they get lost. | |