linux-kernel - Stability guarantees on uevent variables?

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: <c0d32695-9e3e-4173-8448-7d123f38824e@notapiano>
Date:   Thu, 24 Aug 2023 19:08:39 -0400
From:   Nícolas F. R. A. Prado 
        <nfraprado@...labora.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        linux-kernel@...r.kernel.org, kernel@...labora.com
Subject: Stability guarantees on uevent variables?

Hi,

my question boils down to the following:

Is there a stability guarantee on the format and content of the variables in
uevents produced by the kernel?

I would assume so, given that uevents are explicitly produced for userspace, and
users will rely on them. However, looking through the ABI documentation I could
only find two instances of uevents being defined (testing/usb-uevent and
testing/usb-charger-uevent) and neither mention the variables added in the
KOBJ_ADD action. The document for the uevent file in sysfs,
testing/sysfs-uevent, only mentions writing synthetic uevents, rather than
reading existing ones. Is the documentation simply lacking or is it intentional
that uevent variables aren't covered?

I'm particularly interested in the format for the MODALIAS uevent variable. My
understanding is that its only use is to match against the modules' aliases in
the modules.alias file. For that reason I'm wondering whether for this variable,
the guarantee would only be that the format of the value will match the one in
modules.alias, but the precise format is not guaranteed (for example, a new
field could potentially be introduced in the future if added to both the device
uevent and module's alias). However, I do see a few ABI documentation pages for
the modalias file in sysfs (eg in testing/sysfs-bus-pci), which explicitly
describe the format, and that's supposed to be the same as the MODALIAS uevent,
so does that mean the format itself is stable?

I'll be happy to improve the ABI documentation based on the reply to these
questions.

As for the full context for these questions, as part of an effort to improve the
detection of regressions affecting device probe, I want to be able to check
whether devices under a discoverable bus (USB, PCI) were populated and probed by
a driver. We currently do this by checking against driver and device names [1],
but as has been pointed out before, that's not stable ABI, and the test might
break if things get renamed or moved around. So my intention is to change that
check to use modaliases or other uevents to find the device in a stable way and
check for the driver symlink to verify it's been probed.

[1] https://github.com/kernelci/bootrr/blob/3ae9fd5dffc667fa96012892ea08532bc6877276/boards/google%2Cspherion#L279

Thanks,
Nícolas