netdev - Re: [PATCH v2] ptp: Add sysfs attribute to show PTP device is safe to open RO

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]

Message-ID: <2025051956-pawing-defrost-9af3@gregkh>
Date: Mon, 19 May 2025 17:56:25 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Wojtek Wasko <wwasko@...dia.com>
Cc: richardcochran@...il.com, vadim.fedorenko@...ux.dev, kuba@...nel.org,
	andrew@...n.ch, netdev@...r.kernel.org
Subject: Re: [PATCH v2] ptp: Add sysfs attribute to show PTP device is safe
 to open RO

On Mon, May 19, 2025 at 06:30:32PM +0300, Wojtek Wasko wrote:
> Recent patches introduced in 6.15 implement permissions checks for PTP
> clocks [1]. Prior to those, a process with readonly access could modify
> the state of PTP devices, in particular the generation and consumption
> of PPS signals. This security hole was not widely exposed as userspace
> managing the ownership and permissions of PTP device nodes (e.g. udev)
> typically disabled unprivileged access entirely as a stopgap workaround.
> 
> Although the security vulnerability has been fixed in the kernel,
> userspace has no reliable way to detect whether the necessary
> permissions checks are actually in place. As a result, it must continue
> restricting PTP device permissions, even though unprivileged users can
> now be granted readonly access.
> 
> There is little precedent for fixing device permissions security hole
> covered by a long-standing userspace workaround. In previous cases where
> device permission checks were tightened [2-4], there were no userspace
> workarounds to remove/disable and so kernel fixes were applied silently
> without notifying the userspace.
> 
> A possible solution that would not require new ABI is for userspace to
> check the kernel version to detect whether the fix is in place. However,
> this approach is unreliable and error-prone, especially if backports are
> considered [5].
> 
> Add a readonly sysfs attribute to PTP clocks, "ro_safe", backed by a
> static string.
> 
> [1] https://lore.kernel.org/netdev/20250303161345.3053496-1-wwasko@nvidia.com/
> [2] https://lore.kernel.org/lkml/20070723145105.01b3acc3@the-village.bc.nu/
> [3] https://lore.kernel.org/linux-mtd/20200716115346.GA1667288@kroah.com/
> [4] https://lore.kernel.org/linux-mtd/20210303155735.25887-1-michael@walle.cc/
> [5] https://github.com/systemd/systemd/pull/37302#issuecomment-2850510329
> 
> Changes in v2:
> - Document the new sysfs node
> 
> Signed-off-by: Wojtek Wasko <wwasko@...dia.com>
> ---
>  Documentation/ABI/testing/sysfs-ptp | 8 ++++++++
>  drivers/ptp/ptp_sysfs.c             | 3 +++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-ptp b/Documentation/ABI/testing/sysfs-ptp
> index 9c317ac7c47a..1968199dcf1c 100644
> --- a/Documentation/ABI/testing/sysfs-ptp
> +++ b/Documentation/ABI/testing/sysfs-ptp
> @@ -140,3 +140,11 @@ Description:
>  		PPS events to the Linux PPS subsystem. To enable PPS
>  		events, write a "1" into the file. To disable events,
>  		write a "0" into the file.
> +
> +What:		/sys/class/ptp/ptp<N>/ro_safe
> +Date:		May 2025
> +Contact:	Wojtek Wasko <wwasko@...dia.com>
> +Description:
> +        This read-only file conveys whether the kernel
> +        implements necessary permissions checks to allow
> +        safe readonly access to PTP devices.
> diff --git a/drivers/ptp/ptp_sysfs.c b/drivers/ptp/ptp_sysfs.c
> index 6b1b8f57cd95..763fc54cf267 100644
> --- a/drivers/ptp/ptp_sysfs.c
> +++ b/drivers/ptp/ptp_sysfs.c
> @@ -28,6 +28,8 @@ static ssize_t max_phase_adjustment_show(struct device *dev,
>  }
>  static DEVICE_ATTR_RO(max_phase_adjustment);
>  
> +static DEVICE_STRING_ATTR_RO(ro_safe, 0444, "1\n");

This is not how to use sysfs, sorry.  We do NOT use it for "feature
flags" like this.

Userspace should do something else to determine if the feature is there
or not, or just default to "do not allow" if it can not figure it out.

sorry, but this change is not ok.

greg k-h