netdev - Re: loaded router, excessive getnstimeofday in oprofile

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: <20080827.201020.17601834.davem@davemloft.net>
Date:	Wed, 27 Aug 2008 20:10:20 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	juhlenko@...mai.com
Cc:	andi@...stfloor.org, johnpol@....mipt.ru, dada1@...mosbay.com,
	denys@...p.net.lb, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: loaded router, excessive getnstimeofday in oprofile

From: Jason Uhlenkott <juhlenko@...mai.com>
Date: Wed, 27 Aug 2008 19:39:58 -0700

> It's a *socket* option.  It's named SO_TIMESTAMP.  Users of it ought
> to *expect* that it records the time the packet hits the socket, not
> the time the frame hits the device.

When expectations equal reality, and then we change reality, that's
called breaking things.

What might (and I do mean "might") save us is how other systems
implement this.  A quick check of BSD shows that at least OpenBSD
fetches the timestamp inside of the RAW and UDP usrreq handler,
which is basically socket receive.

Our man pages simply say "reception" as when the timestamp is from,
which may also give us some more leeway.
From: Jason Uhlenkott <juhlenko@...mai.com>
Date: Wed, 27 Aug 2008 19:39:58 -0700

> > I find it amusing that nobody it talking about fixing the tools
> > that are creating the timestamp requests when they have no real
> > reason for having them in the first place.
> 
> I don't agree that the tools are broken.  Some of them may have
> frivolous reasons for wanting timestamps, but they're asking for
> something at the socket layer, with the scope of a single socket, and
> it's hardly their fault that we respond to that by doing something
> expensive and global at a much lower level.

Every application using AF_PACKET sockets gets timestamps by
default.  And we do know of several specific cases where the
timestamps are unnecessary.

Even for other cases, why in the world does a DHCP client need
accurate timestamps?  Give me a break. :)

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html