netdev - RE: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the timecompare method

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]

Date:	Mon, 26 Mar 2012 18:56:44 +0000
From:	"Keller, Jacob E" <jacob.e.keller@...el.com>
To:	chetan loke <loke.chetan@...il.com>,
	Richard Cochran <richardcochran@...il.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"Ronciak, John" <john.ronciak@...el.com>,
	"john.stultz@...aro.org" <john.stultz@...aro.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>
Subject: RE: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of
 the timecompare method

> -----Original Message-----
> From: chetan loke [mailto:loke.chetan@...il.com]
> Sent: Monday, March 26, 2012 10:12 AM
> To: Richard Cochran
> Cc: Keller, Jacob E; netdev@...r.kernel.org; e1000-
> devel@...ts.sourceforge.net; Kirsher, Jeffrey T; Ronciak, John;
> john.stultz@...aro.org; tglx@...utronix.de
> Subject: Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the
> timecompare method
> 
> You are confusing 'blocking the driver's fast path' with
> performance/optimization etc. We cannot let user-space code jam the system.
> Kernel code should be designed such that
> bugs(intentional/unintentional) in user-space code cannot cause system wide
> adverse affects. Period.
>
I agree. But I also think a test case should be in order here. What actually
happens with a badly designed user app cramming ioctls. (Note that under most
system designs the ioctls require root access unless you change the default
permissions.)

> Does your existing design limit (ab)users from pounding the ioctls?
> 
> As I mentioned earlier, it could be possible to take care of gettime and the
> driver's Rx/Tx path by using a mixture of locks/kernel-thread.
> But settime/adjtime still needs to be curbed.
> 
I am curious how you see a kernel thread resolving the Tx/Rx issue? or is the
kernel thread being used by gettime? I don't believe we can wait for the Tx/Rx
path, because if we take too long the software sees it as a dropped timestamp.
Also we have a pointer to the skb which is free'd right after the call for
(rx/tx)hwtstamp so we can't just copy that pointer.

> Why isn't ioctl-rate limiting acceptable? Let's say an app that is trying to
> set/adj NIC counter is running on host side then how often would it need to
> read and correct/set/adj? once every msec(so 1000 times a second), once every
> 10 msec(100 times a second) etc?
> 
> So, will pounding the ioctl 1000 times, while processing ~820K
> frames(1500 byte payload on 10G link) still cause a problem for the driver is
> what we would need to see. rate can also be a factor of link-speed(?).
> 
> And we don't need 100 such apps. Only 1 app should be working in tandem with
> the NIC. If other apps fail then atleast the sysadmin or users would know
> someone else is (ab)using it.

How would we only allow one app? Any app with permissions could call the ioctls.
I do agree that having too many ioctls is a problem. Even in cases where PTP is
only enabled on a "trusted" system. Allowing the kernel to assume the system
is trusted means we introduce security holes. I am not sure of the right solution
or whether we need a different one, though. I am going to try and provide a test case
where someone hammers the ioctls in a loop, and see what happens.

> 
> 
> > Thanks,
> > Richard
> 
> Chetan