| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-11 | |||
| 17:04:22 | efried | seems like yet another thing we shouldn't start fixing as part of this series, but should do later when we can be more complete | |
| 17:04:40 | sean-k-mooney | i guess | |
| 17:04:51 | artom | dansmith, clearly not enough :( | |
| 17:05:00 | efried | f man, if we try to fix everything ugly we notice or touch or get near, we'll never get anything done anywhere ever. | |
| 17:05:01 | sean-k-mooney | what is the behavior when we raise we go to error then we clean it up later? | |
| 17:05:11 | sean-k-mooney | i assume that woudl jsut fail again | |
| 17:05:20 | dansmith | artom: fix those quick so I can apply my +2 and we can move on | |
| 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 | |