Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interpretation of SMBIOS string characters is ambiguous #31

Closed
jrgerber opened this issue Feb 27, 2021 · 0 comments · Fixed by #34
Closed

Interpretation of SMBIOS string characters is ambiguous #31

jrgerber opened this issue Feb 27, 2021 · 0 comments · Fixed by #34
Assignees
Labels
invalid This doesn't seem right question Further information is requested

Comments

@jrgerber
Copy link
Owner

jrgerber commented Feb 27, 2021

The DMTF standard never states what type of characters BIOS stores in its strings. One can infer from the long history of BIOS that these characters are ASCII but even if it did state just ASCII there is still room for interpretation.

BIOS strings are 8 bit characters with a null terminator. The problem is today's modern computer languages prefer to store strings in a way that accommodates world languages. Rust uses UTF-8 for a char. When using the as operator in Rust to convert from a u8 to a char, it uses From. As described in the documentation:

Maps a byte in 0x00..=0xFF to a char whose code point has the same value, in U+0000..=U+00FF.

Unicode is designed such that this effectively decodes bytes with the character encoding that IANA calls ISO-8859-1. This encoding is compatible with ASCII.

This is the best solution I can think of because it will preserve the original byte value for 0-255. In other words, there should always be 1:1 mapping and never a many to one or one to many. Preserving 1:1 mapping means that you can know with certainty what the BIOS string originally looked like.

Unicode's first 256 values (0-255) are identical to ISO-8859-1. In other words, converting a byte 0xNN to 0x00NN is an ISO-8859-1 conversion between single byte to wide. The operation can easily be reversed.

@jrgerber jrgerber added invalid This doesn't seem right question Further information is requested labels Feb 27, 2021
@jrgerber jrgerber self-assigned this Mar 1, 2021
@jrgerber jrgerber linked a pull request Mar 1, 2021 that will close this issue
mulark pushed a commit that referenced this issue Mar 29, 2022
* Impl oem-strings

* Add oem-string tests

* Fix type
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
invalid This doesn't seem right question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant