Page MenuHomeFreeBSD

bhyve: add configurable SMBIOS OEM Strings
Needs ReviewPublic

Authored by chuck on Wed, Jun 10, 12:58 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Jun 19, 8:36 PM
Unknown Object (File)
Fri, Jun 19, 6:43 PM
Unknown Object (File)
Thu, Jun 18, 12:58 AM
Unknown Object (File)
Wed, Jun 17, 11:23 PM
Unknown Object (File)
Wed, Jun 17, 8:52 PM
Unknown Object (File)
Wed, Jun 17, 3:06 PM
Unknown Object (File)
Wed, Jun 17, 8:54 AM
Unknown Object (File)
Tue, Jun 16, 1:03 PM

Details

Reviewers
markj
corvink
Group Reviewers
bhyve
Summary

Add the option "oemstring" to allow setting the DMI type 11 ("OEM
Strings") SMBIOS structure. These are free-form strings, available for
any purpose, but can be especially useful to pass configuration,
secrets, and credential information into a Linux guest and consumed by
systemd.

MFC after: 1 month
Relnotes: yes

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 73938
Build 70821: arc lint + arc unit

Event Timeline

usr.sbin/bhyve/smbiostbl.c
260

If nstrings is a uint8_t, how can we support 99999 OEM strings?

494
495
832

Why not report an error instead?

842

Again, why not report malformed input instead of silently ignoring it?

858

Why not report this case as an error?

884

Better to use calloc().

911
922

template_strings doesn't get freed anywhere.

930

To me this is clearer as

for (i = 0; template_strings[i].node != NULL; i++)
    ;
936

Spurious change.

chuck added inline comments.
usr.sbin/bhyve/smbiostbl.c
260

Hmm. Going back over this, the DMTF spec defines the header as:
04h | Count | BYTE | Varies Number of strings
so the uint8_t is correct, and the 99,999 number used later is wrong. It appears qemu allows configuring an arbitrary number of these strings but ultimately truncates the count to an 8 bit value.

I'm going to leave this as-is but change the subsequent checks to 255 instead of 99999.

884

The memory contains both the "array" of struct smbios_string plus the strings themselves immediately following the structs. calloc() didn't seem like the obvious choice here, but perhaps I'm missing something?

chuck marked an inline comment as done.

Update based on review feedback + rebase to main

Report unexpected nvlist type as an error per review feedback