[Yahoo-eng-team] [Bug 1753558] [NEW] NoCloud data source is mis-using the "system-serial-number" SMBIOS field, should use "OEM Strings" instead

Daniel Berrange Mon, 05 Mar 2018 10:41:03 -0800

Public bug reported:

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 <berra...@redhat.com>
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 <berra...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>

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 <berra...@redhat.com>
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 <jfer...@redhat.com>
Signed-off-by: Daniel P. Berrange <berra...@redhat.com>

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.

** Affects: cloud-init
Importance: Undecided
Status: New

--
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:
New

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 <berra...@redhat.com>
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