netdev - Re: [PATCH ethtool-next] netlink: tsconfig: add HW time stamping configuration

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: <20251030153723.7448a18e@kmaincent-XPS-13-7390>
Date: Thu, 30 Oct 2025 15:37:23 +0100
From: Kory Maincent <kory.maincent@...tlin.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Vadim Fedorenko <vadim.fedorenko@...ux.dev>, Michal Kubecek
 <mkubecek@...e.cz>, netdev@...r.kernel.org
Subject: Re: [PATCH ethtool-next] netlink: tsconfig: add HW time stamping
 configuration

On Wed, 29 Oct 2025 15:38:12 -0700
Jakub Kicinski <kuba@...nel.org> wrote:

> On Wed, 29 Oct 2025 18:53:20 +0000 Vadim Fedorenko wrote:
> > >> Well, yes, it's only 1 bit is supposed to be set. Unfortunately, netlink
> > >> interface was added this way almost a year ago, we cannot change it
> > >> anymore without breaking user-space API.    
> > > 
> > > The netlink interface only mirrors what we already had in struct
> > > ethtool_ts_info (i.e. the ioctl interface). Therefore my question was
> > > not really about this part of kernel API (which is fixed already) but
> > > rather about the ethtool command line syntax.
> > > 
> > > In other words, what I really want to ask is: Can we be absolutely sure
> > > that it can never possibly happen in the future that we might need to
> > > set more than one bit in a set message?
> > > 
> > > If the answer is positive, I'm OK with the patch but perhaps we should
> > > document it explicitly in the TSCONFIG_SET description in kernel file
> > > Documentation/networking/ethtool-netlink.rst    
> > 
> > Well, I cannot say about long-long future, but for the last decade we
> > haven't had a need for multiple bits to be set up. I would assume that
> > the reality will be around the same.
> > 
> > Jakub/Kory do you have thoughts?  
> 
> hard to prove a negative, is the question leading to a different
> argument format which will let us set multiple bits? Looks like
> we could potentially allow specifying tx / rx-filter multiple
> times? Or invent new keywords for the extra bits which presumably 
> would be somehow orthogonal to filtering?
> 
> tl;dr I'm unclear on the exact concern..

Yes I don't know either. There is already such "orthogonal" flags:
https://elixir.bootlin.com/linux/v6.17.1/source/include/uapi/linux/net_tstamp.h#L180

We could change the bitmap to a value here, even if we don't know what the
future is.
Jakub, as it is already in uAPI but not used at all, would it be possible to
change it or is it already too late?

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com