ds-identify: false positive EC2 detection on non-EC2 platforms due to UUID collision in ec2_identify_platform()

[Redent0r]

Bug report

ds-identify can falsely identify a non-EC2 VM as running on AWS EC2 due to a collision in the UUID-based platform detection heuristic in ec2_identify_platform(). This causes cloud-init to remain enabled on VMs where it should be auto-disabled via the notfound=disabled policy.

In tools/ds-identify, the ec2_identify_platform() function uses two glob patterns on the first group of DMI_PRODUCT_UUID to detect EC2:

local start_uuid="${DI_DMI_PRODUCT_UUID%%-*}"
case "$start_uuid" in
    [Ee][Cc]2*)
        _RET="AWS"
        ;;
    *2[0-9a-fA-F][Ee][Cc])
        _RET="AWS"
        ;;
    *)
        _RET="$default"
        ;;
esac

AWS's own documentation acknowledges this UUID method is potentially inaccurate

False positive example:

DMI_SYS_VENDOR=SomeVendor
DMI_PRODUCT_NAME=Virtual Machine
DMI_PRODUCT_UUID=a83f26ec-1234-5678-abcd-ef0123456789
VIRT=microsoft

First UUID group: a83f26ec
                      ^^^^
                      26ec  → matches *2[0-9a-fA-F][Ee][Cc] → "AWS"

Steps to reproduce the problem

1. Create a VM on any non-EC2 hypervisor
2. Ensure DMI_PRODUCT_UUID first group ends in a pattern matching 2[0-9a-fA-F][Ee][Cc] (e.g., a83f26ec-...)
3. Install cloud-init with default ds-identify policy (notfound=disabled)
4. Boot the VM
5. Observe in /run/cloud-init/ds-identify.log:

ec2 platform is 'AWS'
Found single datasource: Ec2
returning 0

6. cloud-init remains enabled despite no valid datasource being reachable

Suggested fix

The function already checks DMI_SYS_VENDOR for specific cloud providers (e24cloud, Tilaa, Outscale) but does not use it to gate the UUID heuristic. The UUID pattern is inherently a weak signal and should only be trusted when corroborated by a vendor string consistent with EC2. We could use a:

• allowlist (preferred): Only trust the UUID heuristic for known EC2 vendors ("Amazon EC2"|"Xen")

• blocklist: Exclude known non-EC2 hypervisors before the UUID check (eg Microsoft Corporation"|"QEMU"|"Red Hat"|"Nutanix"|"Google")

Option A is preferred because it is forward-compatible — any new platform with random UUIDs is automatically excluded, whereas Option B requires adding entries for each new vendor.

Environment details

• Cloud-init version: 24.3.1
• Operating System Distribution: AzureLinux
• Cloud provider, platform or installer type: Azure

[cjp256]

I was surprised it even considered the EC2 datsource given that Azure Linux images configure a restricted data source list including Azure + NoCloud.

I looked through the logs and looked at ds-identify and realized that AZL3 is using a multi-line datasource_list config which forever whatever reason the authors of ds-identify didn't think was valid.

$ head -n4 /run/cloud-init/ds-identify.log
[up 2.09s] ds-identify
policy loaded: mode=search report=false found=all maybe=none notfound=disabled
/etc/cloud/cloud.cfg set datasource_list: [
WARN: no datasource_list found, using default: MAAS ConfigDrive NoCloud AltCloud Azure Bigstep CloudSigma CloudStack DigitalOcean Vultr AliYun Ec2 GCE OpenNebula OpenStack OVF SmartOS Scaleway Hetzner IBMCloud Oracle Exoscale RbxCloud UpCloud VMware LXD NWCS Akamai WSL

If I consolidate the multi-line config into a single-line config in /etc/cloud/cloud.cfg, we will now see:

$ head -n4 /run/cloud-init/ds-identify.log
[up 2.26s] ds-identify
policy loaded: mode=search report=false found=all maybe=none notfound=disabled
/etc/cloud/cloud.cfg set datasource_list: [ Azure, NoCloud, None ]
DMI_PRODUCT_NAME=Virtual Machine

I took a stab and implementing multi-line support here:
#6883

But I also think these warnings/errors should be captured in cloud-init status escalate them.

[holmanb]

Thanks for digging into this @cjp256.

I looked through the logs and looked at ds-identify and realized that AZL3 is using a multi-line datasource_list config which
forever whatever reason the authors of ds-identify didn't think was valid.

I think this is documented a few places as being single-line, but I'd need to look. I'm guessing that the authors likely just didn't want to implement a complete yaml parser in posix shell.

I took a stab and implementing multi-line support here:

I'll take a look when I can.

But I also think these warnings/errors should be captured in cloud-init status escalate them.

Agreed

It seems the underlying issue was identified, so I'm closing this.