In-kernel parser for the BMOF format used by WMI-ACPI

In-kernel parser for the BMOF format used by WMI-ACPI

[Armin Wolf]

Hello,

since around 2017 we are able to partially decode the Binary MOF (BMOF) data used to describe the interfaces of WMI-ACPI
devices found inside modern devices. This initial reverse-engineering was done by Pali Rohár and implementing a BMOF parser
inside the kernel was originally also proposed by him (see https://lore.kernel.org/lkml/201706041809.21573@pali/T/).

As part of my bachelor thesis i finished the reverse-engineering and created yet another utility for parsing BMOF data.
This utility can be found at github (https://github.com/Wer-Wolf/tarkin) and i now intend to use it to finally implement
a BMOF parser inside the kernel.

There exists a growing list of WMI drivers using quirk tables for detecting the presence of specific WMI methods on a given
device. This approach is maintenance-intensive and not exactly user friendly (end users rarely send kernel patches). Because
of this we need this BMOF parser so that we can check which WMI methods are available.

My current idea for this BMOF parser looks like this:

  - support for the MS-DOS Doublespace compression algorithm (only decompression) lands in lib/ds/

  - WMI driver core moves into drivers/platform/x86/wmi/

  - a new component called the WMI repository will hold all BMOF data known to the kernel (necessary to emulate the WMI infrastructure under Windows)

  - parsing of BMOF data is only done by the WMI repository which exposes a in-kernel API under include/linux/wmi/repository.h

  - BMOF data can be loaded into the WMI repository by the wmi-bmof driver (for firmware-provided BMOF data) or by WMI drivers themself (for WMI devices with firmware-provided BMOF data)

The remaining questions are:

  - How to structure the library code inside /lib/ds/?

  - Is there any way to check whether the Doublespace compression algorithm is still encumbered by patents?

  - Can BMOF files used by WMI drivers be included inside linux-firmware even if they only hold configuration data?

I would be very happy if the relevant maintainers could comment on the above questions.

Thanks,
Armin Wolf

Re: In-kernel parser for the BMOF format used by WMI-ACPI

[Pali Rohár]

On Tuesday 11 March 2025 21:06:16 Armin Wolf wrote:
>  - Is there any way to check whether the Doublespace compression algorithm is still encumbered by patents?

Linux kernel 2.2 or 2.4 had full read/write support for doublespace
compression algorithm in mainline kernel and it was connected with fat
driver. IIRC it was dropped for kernel 2.6 because nobody ported that
vfat code to new fs API and hence doublespace in-kernel compression
algorithm was not needed/used anymore. But I do not remember details.

So IMHO it should not be a problem to reintroduce same code into kernel
again if there is a new need for it.

And in my project I reused the doublespace compression code from old
Linux kernel.

Re: In-kernel parser for the BMOF format used by WMI-ACPI

[Armin Wolf]

Am 11.03.25 um 21:13 schrieb Pali Rohár:

> On Tuesday 11 March 2025 21:06:16 Armin Wolf wrote:
>>   - Is there any way to check whether the Doublespace compression algorithm is still encumbered by patents?
> Linux kernel 2.2 or 2.4 had full read/write support for doublespace
> compression algorithm in mainline kernel and it was connected with fat
> driver. IIRC it was dropped for kernel 2.6 because nobody ported that
> vfat code to new fs API and hence doublespace in-kernel compression
> algorithm was not needed/used anymore. But I do not remember details.
>
> So IMHO it should not be a problem to reintroduce same code into kernel
> again if there is a new need for it.
>
> And in my project I reused the doublespace compression code from old
> Linux kernel.

AFAIK only the CVF code used by the dmsdos driver was inside the mainline kernel,
but not the dmsdos driver itself.

Thanks,
Armin Wolf

Re: In-kernel parser for the BMOF format used by WMI-ACPI

[Pali Rohár]

On Tuesday 11 March 2025 21:59:29 Armin Wolf wrote:
> Am 11.03.25 um 21:13 schrieb Pali Rohár:
> 
> > On Tuesday 11 March 2025 21:06:16 Armin Wolf wrote:
> > >   - Is there any way to check whether the Doublespace compression algorithm is still encumbered by patents?
> > Linux kernel 2.2 or 2.4 had full read/write support for doublespace
> > compression algorithm in mainline kernel and it was connected with fat
> > driver. IIRC it was dropped for kernel 2.6 because nobody ported that
> > vfat code to new fs API and hence doublespace in-kernel compression
> > algorithm was not needed/used anymore. But I do not remember details.
> > 
> > So IMHO it should not be a problem to reintroduce same code into kernel
> > again if there is a new need for it.
> > 
> > And in my project I reused the doublespace compression code from old
> > Linux kernel.
> 
> AFAIK only the CVF code used by the dmsdos driver was inside the mainline kernel,
> but not the dmsdos driver itself.

Ok, probably I remember it incorrectly. It is too long ago.

Re: In-kernel parser for the BMOF format used by WMI-ACPI

[Kurt Borja]

On Tue Mar 11, 2025 at 3:06 PM -05, Armin Wolf wrote:
> Hello,
>
> since around 2017 we are able to partially decode the Binary MOF (BMOF) data used to describe the interfaces of WMI-ACPI
> devices found inside modern devices. This initial reverse-engineering was done by Pali Rohár and implementing a BMOF parser
> inside the kernel was originally also proposed by him (see https://lore.kernel.org/lkml/201706041809.21573@pali/T/).
>
> As part of my bachelor thesis i finished the reverse-engineering and created yet another utility for parsing BMOF data.
> This utility can be found at github (https://github.com/Wer-Wolf/tarkin) and i now intend to use it to finally implement
> a BMOF parser inside the kernel.

It most be a very cool thesis project, I'll look into tarkin.

>
> There exists a growing list of WMI drivers using quirk tables for detecting the presence of specific WMI methods on a given
> device. This approach is maintenance-intensive and not exactly user friendly (end users rarely send kernel patches). Because
> of this we need this BMOF parser so that we can check which WMI methods are available.

A BMOF parser in-kernel is definetly a game changer for a lot of
drivers. Can't wait to implement this in alienware-wmi! Please, keep me
updated.

I wish you the best for your thesis :)

-- 
 ~ Kurt