NoCloud data source is mis-using the "system-serial-number" SMBIOS field, should use "OEM Strings" instead

This bug was originally filed in Launchpad as [LP: #1753558](https://bugs.launchpad.net/cloud-init/+bug/1753558)

Launchpad details

affected_projects = []

assignee = None

assignee_name = None

date_closed = None

date_created = 2018-03-05T18:33:18.152018+00:00

date_fix_committed = None

date_fix_released = None

id = 1753558

importance = medium

is_complete = False

lp_url = https://bugs.launchpad.net/cloud-init/+bug/1753558

milestone = None

owner = berrange

owner_name = Daniel Berrange

private = False

status = confirmed

submitter = berrange

submitter_name = Daniel Berrange

tags = []

duplicates = []

_Launchpad user **Daniel Berrange(berrange)** wrote on 2018-03-05T18:33:18.152018+00:00_

As the name suggests, the "system-serial-number" field in SMBIOS is intended for exposing a serial number identifying the hardware, to the operating system.

The NoCloud data source is mis-using this field for receiving metadata for initializing cloud-init.

Admittedly there was not really a better alternative available from QEMU historically, if SMBIOS was the required comms channel. This is not true for the SMBIOS spec in general though. It has a specified a table called "OEM Strings" which has no semantics defined and thus intentionally available for passing arbitrary OEM defined data to the guest OS.

This is much better suited to usage by cloud-init, and with careful namespacing it is possible to use "OEM strings" for multiple purposes, not only cloud-init.

Thus I have implemented patches for QEMU to enable use of the "OEM strings" SMBIOS table

  commit 2d6dcbf93fb01b4a7f45a93d276d4d74b16392dd
  Author: Daniel P. Berrange
  Date: Sat Oct 28 21:51:36 2017 +0100

    smbios: support setting OEM strings table

    The cloud-init program currently allows fetching of its data by repurposing of
    the 'system' type 'serial' field. This is a clear abuse of the serial field that
    would clash with other valid usage a virt management app might have for that
    field.

    Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
    exposing of arbitrary vendor specific strings to the operating system. This is
    perfect for use with cloud-init, or as a way to pass arguments to OS installers
    such as anaconda.

    This patch makes it easier to support this with QEMU. e.g.

      $QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test

    Which results in the guest seeing dmidecode data

      Handle 0x0E00, DMI type 11, 5 bytes
      OEM Strings
              String 1: Hello
              String 2: World
              String 3: Tricky,value=test

    It is suggested that any app wanting to make use of this OEM strings capability
    for accepting data from the host mgmt layer should use its name as a string
    prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
    parallel the mgmt app could set

      $QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
            value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os

    which would appear as

      Handle 0x0E00, DMI type 11, 5 bytes
      OEM Strings
              String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
              String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os

    Use of such string prefixes means the app won't have to care which string slot
    its data appears in.

    Signed-off-by: Daniel P. Berrange
    Reviewed-by: Michael S. Tsirkin
    Signed-off-by: Michael S. Tsirkin

This will be in the QEMU 2.12 release due out end of April

And and equivalent patch to libvirt (released yesterday in 4.1.0) to allow it to be configured there and passed into QEMU

  commit 68eed56b2d51e66bb540062fe09f5ffd44e99f6e
  Author: Daniel P. Berrange
  Date: Sat Oct 28 14:56:51 2017 +0100

    conf: add support for setting OEM strings SMBIOS data fields

    The OEM strings table in SMBIOS allows the vendor to pass arbitrary
    strings into the guest OS. This can be used as a way to pass data to an
    application like cloud-init, or potentially as an alternative to the
    kernel command line for OS installers where you can't modify the install
    ISO image to change the kernel args.

    As an example, consider if cloud-init and anaconda supported OEM strings
    you could use something like

        
          cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
          anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
        

    use of a application specific prefix as illustrated above is
    recommended, but not mandated, so that an app can reliably identify
    which of the many OEM strings are targetted at it.

    Reviewed-by: John Ferlan
    Signed-off-by: Daniel P. Berrange

All that's missing now is a patch for cloud-init's NoCloud data source to make it look for data via the OEM strings table, in preference to the system table serial field.

Note in the above commits to QEMU/libvirt I illustrated an example of how to use an application specific prefix in the OEM strings entry to get nice namespacing.

Related bugs:
 * bug 1879294: Support fw_cfg data source
 * bug 1753558: NoCloud should use "OEM Strings" instead of
   system-serial-number
* bug 1691772: provide a way to seed NoCloud from network without image modification.

Start at the NoCloud data source and inspect how it currently reads the system-serial-number SMBIOS field. Determine how OEM Strings data is exposed and should be namespaced, then verify that OEM Strings takes precedence while existing serial-field behavior remains compatible. Done means NoCloud can receive its data through the OEM Strings table as described in the issue.

Written by the indexing model from the issue text.