RE: [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute

[Ping-Ke Shih <pkshih@realtek.com>]

Hi Johannes,

Need your comments on usage of sysfs.

Ping-Ke Shih <pkshih@realtek.com> wrote:
> From: Johnson Tsai <wenjie.tsai@realtek.com>
> 
> Expose the device's Serial Number (SN) and UUID from EFUSE through a
> read-only `hw_info` sysfs attribute on the USB interface device.
> 
> This hardware identification information is essential for user-space
> applications to uniquely identify, track, and manage specific Wi-Fi
> adapters. For example, in automated factory provisioning or device
> management systems, user-space tools rely on the EFUSE SN and UUID
> to bind specific configurations to a physical adapter. Currently,
> standard wireless APIs do not expose this low-level hardware
> information, making this sysfs node the only viable and necessary
> solution for user space to extract this data.
> 
> Relying on debugfs or setuid binaries is unviable for production
> environments, as explicitly requested by Valve (Steam). Steam frequently
> runs inside unprivileged containers (e.g., Flatpak) where debugfs and
> setuid binaries are inaccessible. Furthermore, many end-user systems
> disable debugfs in their kernel configs, and strict access controls
> (SELinux, AppArmor) block it regardless of permissions. Since Steam
> installs as an unprivileged user, setuid deployments are impossible.
> Consequently, exposing this data via a world-readable (0444) sysfs
> node is the only functional approach to ensure reliable, unprivileged
> access across diverse customer systems.
> 
> Example usage from user-space:
>   $ cat /sys/bus/usb/devices/2-3.1.2:1.0/hw_info
>   SN: 36 42 00 01 23
>   UUID: aa ec 2b 7c 0a 55 47 27 8d e0 b3 0f eb cc bb aa
> 
> User-space scripts can easily iterate over bound devices to extract
> this information:
>   for dev in /sys/bus/usb/drivers/rtw89_8852cu/[0-9]*:*; do
>       dev_id=$(basename "$dev")
>       echo "--- Device: /sys/bus/usb/devices/$dev_id ---"
>       cat "$dev/hw_info"
>   done
> 
> Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
> ---
> Hi maintainers,
> 
> We are submitting this RFC to discuss the most appropriate upstream path for
> exposing hardware-specific IDs to unprivileged container environments.
> 
> 1. Given the strict environment limitations (Flatpak, missing debugfs, LSMs),
>    is a read-only sysfs attribute acceptable for this specific hardware data?
> 2. If exposing this globally via sysfs is not preferred, would it be acceptable
>    to restrict the creation of this node to specific vendor VID/PIDs only?
> 3. If sysfs is strictly a no-go for this use case, what is the upstream-recommended
>    method for an unprivileged, sandboxed application to retrieve eFuse data?

I also looked up lore.kernel.org and only found a thread commented by Kalle [1].
However, it is not clear to us if sysfs is suitable to read efuse SN/UUID.

[1] https://lore.kernel.org/linux-wireless/87ziib3da5.fsf@kamboji.qca.qualcomm.com/

> ---
>  drivers/net/wireless/realtek/rtw89/usb.c | 51 +++++++++++++++++++++++-
>  1 file changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtw89/usb.c b/drivers/net/wireless/realtek/rtw89/usb.c
> index c6d55e669776..53dcb84af5c0 100644
> --- a/drivers/net/wireless/realtek/rtw89/usb.c
> +++ b/drivers/net/wireless/realtek/rtw89/usb.c
> @@ -1059,6 +1059,41 @@ static void rtw89_usb_intf_deinit(struct rtw89_dev *rtwdev,
>  	usb_set_intfdata(intf, NULL);
>  }
> 
> +static ssize_t hw_info_show(struct device *dev,
> +			    struct device_attribute *attr, char *buf)
> +{
> +	struct usb_interface *intf = to_usb_interface(dev);
> +	struct ieee80211_hw *hw;
> +	struct rtw89_dev *rtwdev;
> +	struct rtw89_efuse *efuse;
> +	ssize_t ret;
> +
> +	device_lock(dev);

I think it isn't necessary to do lock/unlock in show ops. We will revise
it by v2.

[...]

Thanks
Ping-Ke