| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-10-22 | |||
| 09:55:24 | sean-k-mooney | ah, and form that i tatke it the image is in raw? format based on the call to fetch_to_raw | |
| 09:56:01 | zigo | Correct. The image is an upload from another cloud's /var/lib/nova/instance/<uuid>/disk | |
| 09:56:52 | zigo | Will it go nicer if I convert to Qcow2 first? | |
| 09:57:47 | sean-k-mooney | it would work in either case | |
| 09:58:10 | sean-k-mooney | i suspect its failing somehwere here https://github.com/openstack/oslo.utils/blob/master/oslo_utils/imageutils/format_inspector.py#L1388-L1421 | |
| 09:58:29 | sean-k-mooney | however i woudl expect a more verbose excetion message in that case | |
| 09:59:20 | zigo | The image is, as much as I can tell, made from the Debian one, with grub-cloud, dual boot (ie: UEFI + mbr). | |
| 09:59:49 | zigo | At least it looks like it, I didn't check much, but it has all of the usual partitionning. | |
| 10:03:40 | sean-k-mooney | is it publicly aviable or would you beable to provide say the first 1mb of the image which has the format info so we coudl inspect it | |
| 10:04:08 | zigo | I'll investigate myself first. It's not a public image, it's customer's data. | |
| 10:04:09 | sean-k-mooney | we dont actully need the full image all the gpu info is in the first few KBs | |
| 10:04:14 | sean-k-mooney | ack | |
| 10:05:07 | sean-k-mooney | on master we provided a cli that you can use to run the inspector https://github.com/openstack/oslo.utils/blob/master/oslo_utils/imageutils/cli.py | |
| 10:05:45 | sean-k-mooney | so you can do python -m oslo_utils.imageutils -i /path/to/image [-v|--verbose] | |
| 10:05:48 | zigo | Ah, nice ! :) I can try it in my Flamingo virtualized test cluster then. | |
| 10:06:07 | sean-k-mooney | its in epoxy too | |
| 10:06:21 | sean-k-mooney | just not 2024.2 | |
| 10:06:39 | sean-k-mooney | https://github.com/openstack/oslo.utils/blob/stable/2025.1/oslo_utils/imageutils/cli.py | |
| 10:07:29 | zigo | It's a shame there's no script entry point then. | |
| 10:07:31 | sean-k-mooney | the master just has type hints | |
| 10:08:20 | sean-k-mooney | well there is a __main__.py for the module | |
| 10:08:35 | zigo | Yeah, but something in /usr/bin would have been much nicer. | |
| 10:08:37 | sean-k-mooney | but you can basiclly just copy paste it somehwere and run it with the older version of oslo | |
| 10:08:44 | zigo | I'll see if I can push such patch ! :) | |
| 10:09:06 | zigo | Oh, I see. Ok, thanks. | |
| 10:09:07 | sean-k-mooney | i think we did that to not pullute /usr/bin with a debug helper | |
| 10:09:34 | sean-k-mooney | but i dont really have a strong opionion either way | |
| 10:10:29 | sean-k-mooney | if we wanted it to be a cli in /bin all that really needed is addting the console_scripts entry point ot setup.cfg to point at the cli module | |
| 10:11:12 | sean-k-mooney | although on master yo uwoudl now do that via pyproject.toml i think | |
| 10:12:10 | zigo | python3 -m oslo_utils.imageutils -i /path/to/disk <--- Shows nothing, just exists. This means validated in Flamingo ? | |
| 10:13:08 | sean-k-mooney | zigo: anyway my hunch is the mbr is subtlly invalid and not fully complient with the gpt spec | |
| 10:13:19 | sean-k-mooney | am thatm mean our error handleing sucks :) | |
| 10:13:25 | sean-k-mooney | try adding -v | |
| 10:13:53 | zigo | ACTUAL_SIZE=262144 | |
| 10:13:53 | zigo | VIRTUAL_SIZE=262144 | |
| 10:13:53 | zigo | SAFETY_CHECK_PASSED=False | |
| 10:13:53 | zigo | # python3 -m oslo_utils.imageutils -v -i /path/to/disk | |
| 10:13:55 | zigo | IMAGE_FORMAT="gpt" | |
| 10:13:57 | zigo | OSLO_UTILS_VERSION="9.1.0" | |
| 10:14:00 | zigo | FAILURE_REASONS='mbr: GPT MBR has invalid start CHS' | |
| 10:14:14 | sean-k-mooney | there you go | |
| 10:14:23 | zigo | Great, that was very helpful sean! | |
| 10:14:26 | sean-k-mooney | lookign at the code it exits 0 on success and 1 on failure by default | |
| 10:15:09 | sean-k-mooney | so that is form here https://github.com/openstack/oslo.utils/blob/stable/2025.2/oslo_utils/imageutils/format_inspector.py#L1267-L1270 | |
| 10:19:05 | sean-k-mooney | so that path means that the os type is 0xEE a protective MBR https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html#os-types | |
| 10:25:15 | sean-k-mooney | the check that is failign is "(starth, starts, startt) != (0x00, 0x02, 0x00):" thats StartHead StartSector and StartTrack | |
| 10:25:47 | sean-k-mooney | https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html#protective-mbr-partition-record-protecting-the-entire-disk | |
| 10:26:09 | sean-k-mooney | StartingCHS is 3 bytes Set to 0x000200, corresponding to the Starting LBA field. | |
| 10:42:31 | zigo | I probably will propose a patch to accept more valid values. | |
| 10:43:33 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove legacy placement tables from API DB https://review.opendev.org/c/openstack/nova/+/889086 | |
| 10:43:34 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove legacy columns from main DB https://review.opendev.org/c/openstack/nova/+/889088 | |
| 10:43:34 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove legacy tables from main DB https://review.opendev.org/c/openstack/nova/+/889087 | |
| 10:49:12 | opendevreview | Stephen Finucane proposed openstack/nova master: Remove unused 'shutdown_terminate' flag https://review.opendev.org/c/openstack/nova/+/773156 | |
| 10:49:47 | zigo | stephenfin: Gosh, thanks for the placement db cleanup. It's not like if it was a 5 years old technical dept ... :/ | |
| 10:58:14 | opendevreview | Stephen Finucane proposed openstack/nova master: objects: Remove custom comparison methods https://review.opendev.org/c/openstack/nova/+/472285 | |
| 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 | 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: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 | dansmith: I do not agree with your comment in the review. From your review: | |
| 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? | |