yahoo-eng-team team mailing list archive

[James Falcon <1753558@xxxxxxxxxxxxxxxxxx>]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3133

** Bug watch added: github.com/canonical/cloud-init/issues #3133
   https://github.com/canonical/cloud-init/issues/3133

** Changed in: cloud-init
       Status: Confirmed => Expired

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1753558

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

Status in cloud-init:
  Expired

Bug description:
  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 <berrange@xxxxxxxxxx>
    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 <berrange@xxxxxxxxxx>
      Reviewed-by: Michael S. Tsirkin <mst@xxxxxxxxxx>
      Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx>

  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 <berrange@xxxxxxxxxx>
    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

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

      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 <jferlan@xxxxxxxxxx>
      Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1753558/+subscriptions