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-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 22 Jan 2024 16:03:29 +0100
From: Armin Wolf <W_Armin@....de>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 Hans de Goede <hdegoede@...hat.com>
Cc: Andy Shevchenko <andy@...nel.org>, platform-driver-x86@...r.kernel.org,
 LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] platform/x86: wmi: Use ACPI device name in netlink
 event

Am 22.01.24 um 13:47 schrieb Ilpo Järvinen:

> On Mon, 22 Jan 2024, Hans de Goede wrote:
>> On 1/21/24 21:08, Armin Wolf wrote:
>>> The device name inside the ACPI netlink event is limited to
>>> 15 characters, so the WMI device name will get truncated.
>>>
>>> This can be observed with kacpimon when receiving an event
>>> from WMI device "9DBB5994-A997-11DA-B012-B622A1EF5492":
>>>
>>> 	netlink:  9DBB5994-A997- 000000d0 00000000
>>>
>>> Fix this by using the shorter device name from the ACPI
>>> bus device instead. This still allows users to uniquely
>>> identify the WMI device by using the notify id (0xd0).
>>>
>>> Signed-off-by: Armin Wolf <W_Armin@....de>
>>> ---
>>> Changes since v1:
>>> - use acpi_dev_name() helper function
>> I'm a bit divided on this patch. I agree the new way of doing
>> things is better, but technically this is a bit of a userspace API
>> break.
>>
>> I guess we could hope that nothing depends on the old netlink API
>> format / name but I'm not sure we can rely on that ...
>>
>> Ilpo, Andy do you have any opinion on this ?
> Hi Armin,
>
> Have you tried to conduct debian code search to find the code using this?
>
I did, but i found nothing.

I am also preparing to properly initialize the device_class field in another patch,
and this also has the potential of breaking userspace if some users created custom
acpid configs to listen to those events.

I think we can revert those changes anytime if someones turns out to be actually depending
on them.

Armin Wolf


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ