lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <a18f2f93-c8ee-47af-9446-97e3714fc275@gmx.de>
Date: Tue, 11 Mar 2025 21:06:16 +0100
From: Armin Wolf <W_Armin@....de>
To: Pali Rohár <pali@...nel.org>,
 "linux@...ssschuh.net" <linux@...ssschuh.net>, Kurt Borja
 <kuurtb@...il.com>, akpm@...ux-foundation.org, mcgrof@...nel.org,
 russ.weight@...ux.dev, dakr@...nel.org
Cc: "platform-driver-x86@...r.kernel.org"
 <platform-driver-x86@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: In-kernel parser for the BMOF format used by WMI-ACPI

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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ