WMI ACPI object conversion rules

[Wer-Wolf]

The example WMI ACPI code contains no information on how ACPI objects are serialized into the WMI buffer.
According to this article, driver operate on plain WMI buffers for exchanging data.

So far i found out that:

• ACPI integers seem to be converted into 32 bit WMI integers (even if they are 64 bit long)
• ACPI buffers are copied as-is
• ACPI strings are converted into WMI strings

What i do not know is how ACPI Packages are processed and if the ACPI-WMI mapper takes the alignment of the WMI data items into account. Would it be possible to write a short guide about ACPI object conversion rules for firmware developers?

Thanks,
Armin Wolf

[Wer-Wolf]

Any progress?

[Wer-Wolf]

I did some research myself, and i found found at that ACPI packages are "unpacked" by converting the data items inside with alignment:

• integers: 4 byte
• strings: 2 byte
• buffers: 1 byte

[Wer-Wolf]

I also found out that there is a bug inside the wmiacpi.sys driver which can be triggered by returning an ACPI package containing another ACPI package from an ACPI method.

ASL-Code:

Return (Package () {
    0xabcd,
    Buffer () { 0x1 },
    Package () {
            0xfeed,
            "TEST"
    },
    Buffer () { 0x2 },
    0xabcd
}

Result:

cd ab 00 00 // int
01 // Buffer
00 00 // Type 0 (ACPI_METHOD_ARGUMENT_INTEGER)
04 00 // 4 bytes
ed fe 00 00 // int data
01 00 // Type (ACPI_METHOD_ARGUMENT_STRING)
05 00 // 5 bytes
54 45 53 54 00 // string data "TEST"
...

Basically the driver starts to copy raw _ACPI_METHOD_ARGUMENT_V1 structs when encountering a ACPI package, treating it like a ACPI buffer.

Trying to recursively parse such ACPI packages however will allow the firmware to trigger stack overflows, so the best solution would be to just return an error.

[Wer-Wolf]

Also it seems that there exists a buffer overflow somewhere inside the WMI stack, since when defining an WMI event with a single uint32 payload, the WMI stack somehow accepts ACPI buffers containing only two bytes of data.

The upper two bytes of the resulting uint32 are filled with garbage data, but the lower two bytes contain the data from the buffer.

[yinghany]

Thanks Armin. I’m currently on leave and adding @tomas Lugo ***@***.***> and @Ria ***@***.***> to help investigate. Thanks Yinghan

…

________________________________ From: Armin W. ***@***.***> Sent: Friday, June 21, 2024 9:56 PM To: microsoft/Windows-driver-samples ***@***.***> Cc: Assign ***@***.***> Subject: Re: [microsoft/Windows-driver-samples] WMI ACPI object conversion rules (Issue #1146) Also it seems that there exists a buffer overflow somewhere inside the WMI stack, since when defining an WMI event with a single uint32 payload, the WMI stack somehow accepts ACPI buffers containing only two bytes of data. The upper two bytes of the resulting uint32 are filled with garbage data, but the lower two bytes contain the data from the buffer. — Reply to this email directly, view it on GitHub<#1146 (comment)> or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACVKWOL5RGNEN7ABRVDIIL3ZIT7ZXBFKMF2HI4TJMJ2XIZLTSSBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLAVFOZQWY5LFVEYTQNBRGIYTGMZXURXGC3LFVFUGC427NRQWEZLMVRZXKYTKMVRXIX3UPFYGLLCJONZXKZKDN5WW2ZLOOSTHI33QNFRXHE4CUR2HS4DFVJZGK4DPONUXI33SPGSXMYLMOVS2QMZRG44TCNBYGKBKI5DZOBS2K2LTON2WLJLWMFWHKZNKGIZDANRYGIZTGOBQQKSHI6LQMWSWYYLCMVWKK5TBNR2WLKJRHA2DCMRRGMZTPJ3UOJUWOZ3FOKTGG4TFMF2GK>. You are receiving this email because you were assigned. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[tomas]

@yinghany Please don't mention me again in this repo

[Wer-Wolf]

Any progress so far?

[datasoftco]

50$بتاريخ ٢٢‏/٠٦‏/٢٠٢٤ ٧:٥٣ ص، كتب "Armin W." ***@***.***>: I also found out that there is a bug inside the wmiacpi.sys driver which can be triggered by returning an ACPI package containing another ACPI package from an ACPI method. ASL-Code: Return (Package () { 0xabcd, Buffer () { 0x1 }, Package () { 0xfeed, "TEST" }, Buffer () { 0x2 }, 0xabcd } Result: cd ab 00 00 // int 01 // Buffer 00 00 // Type 0 (ACPI_METHOD_ARGUMENT_INTEGER) 04 00 // 4 bytes ed fe 00 00 // int data 01 00 // Type (ACPI_METHOD_ARGUMENT_STRING) 05 00 // 5 bytes 54 45 53 54 00 // string data "TEST" ... Basically the driver starts to copy raw _ACPI_METHOD_ARGUMENT_V1 structs when encountering a ACPI package, treating it like a ACPI buffer. Trying to recursively parse such ACPI packages however will allow the firmware to trigger stack overflows, so the best solution would be to just return an error. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Wer-Wolf]

It also seems that when converting UTF16 WMI strings to ACPI strings, the driver does not return an error when receiving non-ASCII characters, instead the string is modified (ö -> o, etc)

This might cause big issues if firmware developers are not aware of that.