| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-10-22 | |||
| 11:05:14 | sean-k-mooney | zigo: that is unlikely to be accpeted as there arent more _valid_ vlaues | |
| 11:05:43 | zigo | There sure is! | |
| 11:05:52 | zigo | https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html | |
| 11:05:55 | sean-k-mooney | if the os type is declared as 0xEE then it must be that value or its not a valid GPT partion table acrodign to the spec | |
| 11:05:56 | zigo | Search for CHS. | |
| 11:06:25 | sean-k-mooney | no the other value are only valid if the mbr is a legacy mbr not a protective mbr | |
| 11:06:50 | zigo | In the case of "Protective MBR Partition Record" their are some other valid values. | |
| 11:07:17 | zigo | Right, but then why would OpenStack prevent using "Protective MBR" ? | |
| 11:07:37 | sean-k-mooney | we dont protective mbr requeis it to be exactly 0x000200 | |
| 11:08:16 | zigo | My image is perfectly valid and has 0x00, 0xee, 0xfe | |
| 11:08:33 | zigo | (starth, starts, startt) | |
| 11:08:38 | sean-k-mooney | legacy mbr allows other value but you cant mix thet 2 | |
| 11:09:17 | zigo | I believe the Debian image is mixing them to allow both MBR *AND* uefi. | |
| 11:09:32 | sean-k-mooney | this is somtihng that is often done incorectly when trying to create a image that is both bootable as uefi and bios | |
| 11:09:57 | zigo | This is maybe incorrect, but existing in the wild at least. | |
| 11:10:19 | sean-k-mooney | yep we have encounedre that in other cases too. | |
| 11:10:28 | sean-k-mooney | those are not techinially allowed by the gpt spec | |
| 11:10:33 | sean-k-mooney | there is a way to do it | |
| 11:10:44 | sean-k-mooney | but its often not done correctly | |
| 11:11:05 | sean-k-mooney | we had this dicussion with at leat one other disto | |
| 11:11:13 | zigo | Ok, but then, what our format_inspector is trying ot acheive is *not* checking if some images aren't respecting the GPT specs. We're trying to check if nova/cinder/glance is being hacked... | |
| 11:12:12 | zigo | I wouldn't mind fixing the Debian if it's broken, that's probably the case, but that wont fix the "I cannot migrate my VMs from my old cloud" use case... | |
| 11:12:31 | zigo | (and that's what I'm currently trying to fix) | |
| 11:12:32 | sean-k-mooney | we are tryign to require "valid" boot image and currently that includes a valid GPT partion table | |
| 11:12:51 | sean-k-mooney | let me see if i can find the perio bug | |
| 11:13:00 | sean-k-mooney | i have forgotten much of the context ath this point | |
| 11:13:30 | zigo | Right. We aren't trying to prevent border-line wrongly not respecting the spec images. | |
| 11:13:49 | zigo | Just something that Qemu can boot safely. | |
| 11:14:38 | zigo | It'd be ok to be more respecting the spec if we were writing a spec validation tool for qemu, but that's not our goal ... | |
| 11:14:47 | sean-k-mooney | https://bugs.launchpad.net/oslo.utils/+bug/2091114 | |
| 11:15:03 | zigo | Thanks, reading. | |
| 14:36:01 | Uggla | Does someone knows about https://review.opendev.org/c/openstack/nova-specs/+/964444 ? I mean do we have the owners of this patch around ? | |
| 14:43:23 | sean-k-mooney | i just saw the propal come in yesterday | |
| 14:43:38 | sean-k-mooney | so i dont know anything more beyond what is in the review | |
| 15:30:47 | zigo | dansmith: I do not agree with your comment in the review. From your review: | |
| 15:30:47 | zigo | "Removing checks from a security layer because Debian's images have been wrong for a long time is not a good plan, IMHO." | |
| 15:30:47 | zigo | It is wrong that these magic byte checks are doing any security improvements. Plus I'm not sure where this image is comming from, I'm not sure it's from Debian, but it's been there in our older cloud that I'm trying to migrate. | |
| 15:31:17 | dansmith | zigo: understood :) | |
| 15:31:19 | zigo | IMO, we should re-open the topic during the vPTG. | |
| 15:31:49 | zigo | I do agree some kind of checking is good, and thanks for writing these. | |
| 15:32:34 | zigo | Though blocking existing (customer) VMs that's been there for so long isn't helpful. | |
| 15:32:56 | zigo | If I'm being ignored, I'll cary this as Debian specific patches ... :P | |
| 15:33:04 | dansmith | these things are 100% security related btw.. the configuration of the MBR is read and interpreted by the hypervisor, the emulated BIOS/firmware, etc.. so it's entirely possible there's an attack vector there | |
| 15:33:41 | zigo | At what stage the hypervisor reads it?!? | |
| 15:34:00 | zigo | Shouldn't this be done by the virtual BIOS when booting? | |
| 15:34:08 | zigo | (ie: not even in Qemu) | |
| 15:34:24 | dansmith | the hypervisor is running the virtual bios :) | |
| 15:34:40 | zigo | Well in qemu, no? | |
| 15:35:02 | dansmith | yes.. you know qemu is the thing that was hackable with the previous image attack right? | |
| 15:35:24 | zigo | If there was a way to escape when Qemu boots an HDD, that would be a serious security issue in Qemu. | |
| 15:35:43 | dansmith | escape is not the only attack mode, of course | |
| 15:35:45 | zigo | Well, the thing that was hackable, was the image conversion. | |
| 15:36:06 | dansmith | no it wasnt.. you might want to re-read the bug :) | |
| 15:36:11 | zigo | That's very different from executing sea-BIOS instructions. | |
| 15:36:15 | dansmith | it was literally qemu itself | |
| 15:37:25 | opendevreview | Balazs Gibizer proposed openstack/nova master: Rally job for eventlet-removal https://review.opendev.org/c/openstack/nova/+/960130 | |
| 15:37:34 | zigo | When reading the bootloader stuff?!? | |
| 15:38:42 | dansmith | when reading the image and executing the guest.. not the bootloader specifically, but again, we're talking about being defensive for the *next* thing here | |
| 15:39:33 | dansmith | anyway, re-open the discussion of supporting spec-violating images in the vPTG if you want, and carry debian patches to remove these matches-the-spec image security checks if you think that's the best plan | |
| 15:40:19 | zigo | IMO, here, we're talking about being deffensive against the sea-BIOS being executed and doing weird thing, which is *not* our job, and which is hopefully harmless. | |
| 15:40:52 | zigo | But fine ... :P | |
| 15:41:07 | dansmith | well, I thought that inspecting the details of even things like qcow2 data structures was completely not our job until qemu told us it was | |
| 15:41:13 | zigo | BTW, my first iteration got things wrong, what I added wasn't the boot signature I've found. | |
| 15:41:28 | zigo | I've found (0x00, 0x01, 0x00) | |
| 15:42:02 | zigo | dansmith: Right. It probably deserves a discussion. :) | |
| 15:42:28 | zigo | Thanks for this begining of a chat already. | |
| 15:43:27 | dansmith | personally, I think we've already had the discussion, and we've already had a prior art bug that shows another distro realized they were wrong and posted the easy "make the image match the spec" commands, which we could put in the docs | |
| 15:44:34 | zigo | I probably can also patch the MBR of these old VMs... | |
| 15:44:43 | zigo | I'll see if that path works and let you know. | |
| 15:46:40 | dansmith | maybe glance could have a feature in image conversion to fix these things specifically with parted.. that's something I'd be on board with and probably would address your migration issue | |
| 15:50:56 | sean-k-mooney | zigo: (0x00, 0x01, 0x00) is because of a bug in parted | |
| 15:51:09 | sean-k-mooney | acording to the the flatcar image fix pr anyway | |
| 15:51:22 | zigo | Ah... thanks a lot! :) | |
| 15:51:26 | zigo | I'll look it up. | |
| 15:51:56 | zigo | FYI, the image I'm talking about is probably running Debian Jessie ... :) | |
| 15:52:13 | sean-k-mooney | https://github.com/flatcar/scripts/pull/2668#issuecomment-2660859901 | |
| 15:53:54 | sean-k-mooney | i have no idea how the flatcar image buildign work by the way | |
| 15:54:46 | sean-k-mooney | they provided a workaroudn for old images https://bugs.launchpad.net/oslo.utils/+bug/2091114/comments/12 | |
| 15:56:39 | sean-k-mooney | by the way on the glance side ther eis https://github.com/openstack/glance/blob/master/glance/common/config.py#L123C1-L138 to allow folks to weaken the security | |
| 15:56:57 | sean-k-mooney | but that is not really a good longterm approch and im not conviced that shoudl be in oslo | |
| 15:57:17 | zigo | Surprisingly, Glance isn't complaining, only Nova, not sure why. | |
| 15:57:20 | dansmith | can't (and shouldn't) be in oslo | |
| 15:58:16 | kevko | hi, i am running nova upgrade check FROM caracal container when all others containers (kolla-ansible deployment) are still antelope ... this should pass , shouldn't ? as it is slurp ...but check failed ... is it ok ? https://paste.openstack.org/show/bXbzW9LwWQwQIEu8vEUV/ | |
| 15:58:17 | dansmith | glance hasn't had upload stream safety checks for very long, so depends on what you're upgrading to | |
| 15:58:19 | sean-k-mooney | dansmith: i was honesstly kind of surpised ot see that in glance if im honest i assuem this is planned to be deprecated and remvoed eventually | |
| 15:58:49 | kevko | point is that i will upgrade control plane to caracal ...and my 300 compute servers will be upgraded one by one during the weeks | |
| 15:58:54 | dansmith | sean-k-mooney: yes, I don't like it either | |
| 15:59:34 | sean-k-mooney | kevko: ya you shoudl be able to upgrade the contolers and do the compute later | |
| 16:00:25 | sean-k-mooney | kevko: that looks like you have not rant either the db migration or somethign similar to that | |
| 16:00:38 | sean-k-mooney | it could also be using the wrogn db | |
| 16:01:58 | sean-k-mooney | the compute_id was added by https://github.com/openstack/nova/commit/a47fdef1bfba8b1e2c3279f2c51eda3d8a985ec1 | |
| 16:02:07 | sean-k-mooney | in bobcat | |
| 16:02:35 | kevko | yeah, but nova-status upgrade check command sounds like "this script will tell you if you can upgrade , which of course including db migration " | |
| 16:03:34 | sean-k-mooney | well your using a nova-status form carical but have not applied a db migration form bobcat | |
| 16:03:36 | kevko | sean-k-mooney: as I said ... antelope is slurp ...so upgrade to caracal and caracal's nova-status upgrade check should work no ? | |
| 16:04:05 | sean-k-mooney | i would need to check our doc for if the status check shoudl be done after db sync or not | |
| 16:04:13 | kevko | sean-k-mooney: yeah, but why I should update db migration from bobcat when antelope -> caracal is supported slurp upgrade ? | |
| 16:04:45 | sean-k-mooney | its not that you do them form bobcat it that you woudl run all the caracal ones | |
| 16:04:49 | kevko | that's the point ... | |
| 16:06:37 | kevko | sean-k-mooney: In my understanding of the world, a DB migration is part of the upgrade... which means the upgrade check should take into account that I’m running it before the upgrade, right? At least that makes more sense to me… | |