linux-kernel - WMI probe failure when reprobing

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1252c8fb-8d5f-98ad-b24a-5fabec2e1c8b@gmx.de>
Date:   Sat, 22 Jul 2023 02:09:13 +0200
From:   Armin Wolf <W_Armin@....de>
To:     "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: WMI probe failure when reprobing

Hello,

i just noticed that under some circumstances, ACPI WMI devices might fail to reprobe
when being manually unbound and later rebound.
Example:

1. ACPI WMI device #1 binds and registers WMI device with GUID
"05901221-D566-11D1-B2F0-00A0C9062910", resulting in the device
being named "05901221-D566-11D1-B2F0-00A0C9062910".
2. ACPI WMI device #2 binds and registers WMI device with GUID
"05901221-D566-11D1-B2F0-00A0C9062910", resulting in the device
being named "05901221-D566-11D1-B2F0-00A0C9062910-1".
3. ACPI WMI device #1 is manually unbound and later rebound,
now the WMI device with GUID "05901221-D566-11D1-B2F0-00A0C9062910"
is being named "05901221-D566-11D1-B2F0-00A0C9062910-1" too, since
device naming depends on the number of GUIDs currently known to
the WMI subsystem.
4. A WMI device named "05901221-D566-11D1-B2F0-00A0C9062910-1" already
exists, causing the registration of the new WMI device to fail.

I thought about some possible ways to solve this naming issue:

- symlinks to simulate old WMI devices names, new WMI device names similar to "wmiX" with X being a global unique id
- no symlinks, new WMI device names similar to "wmiX" with X being a global unique id
- use global id instead of GUID number

The first approach has full sysfs backward compatibility but i do not know how to create symlinks inside the "devices"
directory. The second approach is the easiest and cleanest one, but provides no sysfs backward compatibility. The last
approach provides only limited sysfs backward compatibility and only for programs which can handle "<GUID>-X" WMI device
names.

Currently, there is one single stable sysfs ABI entry concerning the WMI subsystem (for wmi-bmof), and two testing
sysfs ABI entries (dell-wmi-privacy, sbl-fw-update). I do not know of any userspace programs relying on these ABIs,
but i suspect there might be a couple of scripts which might be affected.

Which approach should i take to solve this problem?

Armin Wolf