Am 01.11.23 um 05:34 schrieb James Seo:
On Tue, Oct 31, 2023 at 11:34:16PM +0100, Armin Wolf wrote:
Am 31.10.23 um 22:07 schrieb Lukasz Stelmach:
It was <2023-10-31 wto 12:28>, when Guenter Roeck wrote:
On 10/31/23 12:07, Lukasz Stelmach wrote:
[ ... ]
For what it's worth, I personally don't see much value in doing much
more than a machine-limited workaround for now. To me it's clear that
this UTF-16 corner case is a BIOS bug and its consequences are minimal
once a workaround is in place.
Thoughts?
I think this is no BIOS bug, but valid behavior since the Windows ACPI-WMI mapper
converts the ACPI objects into a common buffer format as described here:
https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/driver-defined-wmi-data-items
Hi Armin,
I did see this link when you mentioned it earlier, and I understand that it's
specifying the packed and internally aligned buffer format that WMI on Windows
expects when a Windows driver provides a WMI data block.
This to me is a different question from whether an ACPI object in the BIOS,
one which will be converted to a WMI object by Windows later, should contain
UTF-16. I didn't find a single other example in all the ACPI dumps in the Linux
Hardware Database [1] of such an ACPI object.
So the answer to the question seems like a "SHOULD NOT". And someone at HP
definitely did a bad copy-paste when it came to this BIOS. I feel comfortable
calling it a bug (the leading "4" makes it one in any case).
Not exactly, the leading "4" is a hack:
The string "4BIOS Configuration Change" get converted to "\u0034 \u0042 \u0049 \u004f \u0053 \u0020 \u0043 \u006f \u006e \u0066 \u0069 \u0067
\u0075 \u0072 \u0061 \u0074 \u0069 \u006f \u006e \u0020 \u0043 \u0068 \u0061 \u006e \u0067 \u0065 \u0000",
so without the leading "4", the utf16 string is 52 bytes long.
Since WMI want the utf16 string prefixed with its length (52 = 0x34), the leading "4" was added
since the letter "4" gets converted to \u0034 (0x34 = 52).
So for WMI, the leading "4" gets interpreted as the length of the following utf16 string,
so it is not displayed to WMI data consumers.
I assume that the mapper converts the ACPI string into a WMI string buffer, and that
a common ACPI buffer is just passed as-is. In this case, the error lies inside the
linux WMI subsystem, which does not do such a conversion.
I can try to find out more about this conversion and its rules, and use this to add
support for that to the WMI subsystem. This would prevent such errors in the future
and would bring us closer to full ACPI WMI support inside the kernel.
Yes, if the ACPI-WMI mapping driver handles already existing UTF-16 in an ACPI
buffer as we have here, it would be good for us to support that as well.
Hopefully Łukasz can find a Windows machine to help determine if it does.
Earlier, you mentioned converting an ACPI object into the packed buffer format
that Windows expects. But is there some reason I'm missing for us to also pack
things like that in the first place? I assume that this format exists for
convenience (returning multiple values) or space reasons, and such a WMI
buffer is eventually unpacked into its various components according to the MOF
anyway. At least for WMI drivers on Linux, I think it would make more sense to
transparently convert the UTF-16 string to UTF-8 and pretend that the property
was an ACPI_TYPE_STRING all along.
And now I'm thinking out loud, but if WMI doesn't allow arbitrary binary data
(and from the WMI buffer spec you linked, it doesn't), and the Windows ACPI-WMI
mapper can indeed handle UTF-16, then ACPI_TYPE_BUFFER in ACPI objects intended
to become WMI objects can only contain UTF-16.
On my machine (Dell Inspiron 3505), an ACPI WMI method uses a ACPI_TYPE_BUFFER
to pass an array of u32, so assuming ACPI_TYPE_BUFFER == utf16 is false.
This shows why linux should do this preprocessing too, because WMI marshals
the _converted_ buffer using the MOF definitions, not the ACPI bobject.
According to Microsoft documentation, the ACPI-WMI mapper converts the ACPI object
without having _any_ knowledge of the corresponding MOF definitions. This means
that after conversion, the contents of the WMI buffer are only "normalized" so
the WMI core does not have to know about ACPI data types.
If linux would also do this "normalization" step, then we would also be able to
operate on this "normalized" WMI buffer without relying on the ACPI data types,
which (like in this case) can use different ways to express the same WMI data
(string as ACPI string vs string as utf16 buffer).
Armin Wolf
This will take quite some time however, so i would suggest adding a quirk handler
first and replace this with the WMI conversion functions later.
No worries.
[1] https://github.com/linuxhw/ACPI/
