| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-11 | |||
| 17:05:33 | mriedem | artom: https://review.opendev.org/#/c/634606/85 | |
| 17:05:38 | mriedem | FUP needed but won't block | |
| 17:06:09 | artom | Ack, thanks | |
| 17:07:48 | sean-k-mooney | efried: ok so we will just leave it raise. | |
| 17:08:17 | efried | ++ | |
| 17:08:25 | sean-k-mooney | efried: its not that i want to fix every ugly thing we see. i just dont want use adding more | |
| 17:08:46 | efried | Yeah, I understand, but in this case it would entail reengineering the whole exception flow. | |
| 17:08:51 | sean-k-mooney | as long as we dont return the namesapce to the pool of alocatable ones then its fine | |
| 17:08:57 | sean-k-mooney | if we did it woudl be a CVE | |
| 17:09:01 | efried | right, IIUC we're careful enough about that. | |
| 17:09:16 | sean-k-mooney | even if you delete the vm | |
| 17:09:18 | efried | I think in all cases where we could have leaked a pmem, we scrub it. | |
| 17:09:52 | mriedem | now that sean jinxed it | |
| 17:10:25 | sean-k-mooney | if only the hardware did secure erase.... | |
| 17:10:37 | efried | what was that unix util called? | |
| 17:10:41 | efried | shred | |
| 17:10:47 | sean-k-mooney | dban? | |
| 17:10:59 | sean-k-mooney | shred is proably a thing too | |
| 17:11:24 | efried | shred exists on my ubuntu. dban doesn't. | |
| 17:11:47 | mriedem | shred is used in the lvm image backend code | |
| 17:11:52 | artom | dansmith, you made me enable spell check for vim | |
| 17:11:55 | sean-k-mooney | dban is not a utility its a thing you boot https://dban.org/ | |
| 17:12:32 | efried | anyway, I would think a VM wouldn't be able to go looking at a low enough level to recover regular-deleted data. | |
| 17:12:47 | sean-k-mooney | efried: of couse it can | |
| 17:12:49 | efried | thought you needed specialized hardware for that | |
| 17:12:59 | sean-k-mooney | its directly mapped into the guests adress speace | |
| 17:13:04 | sean-k-mooney | it is byte adressable | |
| 17:13:14 | efried | right, but if it's deleted | |
| 17:13:16 | sean-k-mooney | that is why we need to 0 it out | |
| 17:13:46 | efried | isn't that what daxio -z does?? | |
| 17:13:58 | sean-k-mooney | efried: there is no filesystem so to delete it you have to write over it | |
| 17:14:00 | sean-k-mooney | and yes | |
| 17:14:06 | dansmith | artom: no, you did. | |
| 17:14:15 | artom | dansmith, that was a good thing :) | |
| 17:14:41 | dansmith | efried: uh what? | |
| 17:14:43 | efried | sean-k-mooney: yeah, so what I'm saying is, having daxio -z'd the thing, you would need specialized hardware to try to uncover the ghost data | |
| 17:14:44 | mriedem | artom: i've piled on | |
| 17:14:56 | efried | dansmith: what what? | |
| 17:15:05 | sean-k-mooney | efried: you would be surpriesed | |
| 17:15:09 | dansmith | efried: unless you scrub every byte in what you hand to the guest, it can find it | |
| 17:15:24 | efried | scrub meaning overwrite multiple times? | |
| 17:15:28 | sean-k-mooney | efried: yes | |
| 17:15:53 | efried | and... is that not a problem for regular ol ram and disk too? | |
| 17:15:59 | sean-k-mooney | at least with magnetic media there was a bias that a singel over write was not enough | |
| 17:16:13 | efried | do we srsly shred every byte of those between VMs? | |
| 17:16:16 | dansmith | efried: certainly not for ram because it's paged in | |
| 17:16:16 | sean-k-mooney | ram is not persetend so no power no data | |
| 17:16:38 | dansmith | efried: the kernel can zero a page before it lets you read from it if you haven't written to it | |
| 17:17:02 | dansmith | but with media that's not the case | |
| 17:17:20 | dansmith | I dunno what the semantics of the daxio thing are, but in general you have to be careful about that stuff | |
| 17:17:37 | efried | -z, --zero Zero the output device for len size, or the entire device if no length was provided. The output device must be a Device DAX device. | |
| 17:17:47 | dansmith | and there have been exploits where even dropping the map could be circumvented by tricking the thing into granting you access to a region again without it being zeroed | |
| 17:18:03 | efried | I mean, it doesn't say "Really really zero the output device" | |
| 17:18:09 | efried | but still | |
| 17:18:15 | efried | you would think it would be set up to prevent contamination | |
| 17:18:19 | dansmith | efried: and for silicon, it almost never does because it costs money (i.e. wears the media) | |
| 17:18:20 | efried | otherwise what good is it? | |
| 17:18:51 | sean-k-mooney | efried: anyway were are side tracking | |
| 17:18:58 | efried | agreed | |
| 17:19:01 | dansmith | efried: you said "regular deleted data" above, which is what I took exception to | |
| 17:19:30 | efried | ack | |
| 17:19:38 | sean-k-mooney | right its specal hadware that needs special handeling | |
| 17:19:39 | dansmith | but I will say, all the spectre stuff is about sussing out data via sidechannel which is not reading it direclty | |
| 17:19:44 | dansmith | so let's not pretend that's not a thing :) | |
| 17:19:52 | efried | Yeah, of course if you just trash the inode and don't actually zero the content | |
| 17:20:29 | efried | I'm talking about: if you overwrite with zeros, but just once, don't you need something special (that VMs don't have) to read the ghost data? | |
| 17:20:46 | dansmith | not necessarily | |
| 17:20:53 | efried | okay | |
| 17:20:55 | dansmith | you're thinking about low-level hardware detection of things, | |
| 17:21:04 | dansmith | but that's not the only way to get access to that "ghost" data | |
| 17:21:17 | dansmith | that's the whole point of sidechannel attacks | |
| 17:22:02 | alex_xu | efried: do we have something to ignore a host for placement allocation_candidates call now? | |
| 17:22:04 | efried | alex_xu, sean-k-mooney: looks like the CI fixups have merged now https://github.com/intel/Intel-OpenStack-CI-jobs/pull/2 | |
| 17:22:04 | efried | We still have some more minor deltas to do right? | |
| 17:22:26 | efried | alex_xu: you mean something like in_tree=!$uuid ? | |
| 17:22:32 | alex_xu | yes | |
| 17:23:10 | sean-k-mooney | i havent done a full review but the inital change i have looked at seam correct | |
| 17:23:35 | efried | alex_xu: I don't think so. cdent, we haven't done !in_tree yet, right? | |
| 17:23:48 | efried | alex_xu: why? | |
| 17:24:06 | efried | oh | |
| 17:24:08 | alex_xu | efried: for his https://review.opendev.org/#/c/681383/5/nova/scheduler/manager.py@155 | |
| 17:24:36 | alex_xu | if we have that, then we can ignore the src host for the same host resize | |
| 17:24:40 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Deprecate CONF.workarounds.enable_numa_live_migration https://review.opendev.org/640021 | |
| 17:24:40 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Functional tests for NUMA live migration https://review.opendev.org/672595 | |
| 17:25:14 | alex_xu | efried: emm...or we do a manually filter after that | |
| 17:25:18 | sean-k-mooney | all the numa jobs just got killed | |
| 17:25:52 | artom | mriedem, dansmith ^^ | |
| 17:26:13 | efried | alex_xu: Isn't this the famous "doubled allocations" bug? | |
| 17:26:30 | alex_xu | efried: no, it isn't | |
| 17:27:07 | alex_xu | efried: when a host enable same host resize, and that host is the only host has available PCPU now. | |
| 17:27:22 | sean-k-mooney | alex_xu: cant ever ignore the source host for same host reszie or rebuild | |
| 17:27:40 | efried | yeah, I would think for same-host resize we would want to restrict to *only* the current host | |
| 17:27:53 | efried | ...having calculated the positive difference from our current allocations | |
| 17:27:53 | alex_xu | efried: we will try to allocate PCPU in placement, and yes, placement tell you the source host has PCPU, but later the scheduler will check ignore host, the source host is in the ignore host. so the scheduling failed. | |
| 17:28:06 | dansmith | efried: you don't know you're doing a same-host resize | |
| 17:28:19 | efried | oh, bummer | |
| 17:28:23 | alex_xu | sean-k-mooney: sorry, I mean the enable same host resize | |
| 17:28:27 | alex_xu | oops | |
| 17:28:35 | alex_xu | disalbe the same host resize | |
| 17:28:40 | sean-k-mooney | same host resize with pcpus is way more involved | |