linux-kernel - Re: LinuxPPS & spinlocks

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] [day] [month] [year] [list]

Message-ID: <alpine.LFD.0.999.0708020421310.8258@enigma.security.iitk.ac.in>
Date:	Thu, 2 Aug 2007 04:33:46 +0530 (IST)
From:	Satyam Sharma <satyam@...radead.org>
To:	Christopher Hoover <ch@...gatroid.com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: LinuxPPS & spinlocks

Hi,


On Wed, 1 Aug 2007, Christopher Hoover wrote:

> Satyam Sharma <satyam <at> infradead.org> writes:
> > On Mon, 30 Jul 2007, Rodolfo Giometti wrote:
> > 
> > > On Mon, Jul 30, 2007 at 10:33:35AM +0530, Satyam Sharma wrote:
> > > Currently the RFC says to you that you should open the serial port:
> > > 
> > > 	fd = open("/dev/ttyS0", ...);
> > 
> > No, it does *NOT*. All it says is:
> > 
> >     The time_pps_create() is used to convert an already-open UNIX file
> >     descriptor, for an appropriate special file, into a PPS handle.
> > 
> > See? What I said is precisely the implementation the RFC envisages
> > (and the only sane way to implement it too).
> 
> If we were totally rigurous about representing each device as a device node, 
> your solution would be fine.  But we don't.

Of course.

> The clocksource model (/sys/devices/system/clocksource) is a better way to 
> go.  One sysfs file is used to enumerate the possible sources and another is 
> used to read or set the current source.   No new system calls; no new ioctls.

Oh, not introducing any syscalls _at all_ would be fine, too. But the
RFC does /require/ an implementation to have them. I was only mentioning
the kind of implementation the RFC had in mind. But there are other ways
to achieve the same end goal, and yes, probably it's better to avoid
introducing syscalls in the first place and think of other mechanisms.

[ It's not that we're talking of IPsec or IPv6 or something here --
  so RFC-compliance isn't overly important. But the final result
  needs to be good, secure and well-designed, still. ]


Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/