linux-kernel - Re: [PATCHv3 05/16] pps: access pps device by direct pointer

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: <20100809124741.GC20272@gundam.enneenne.com>
Date:	Mon, 9 Aug 2010 14:47:41 +0200
From:	Rodolfo Giometti <giometti@...eenne.com>
To:	Alexander Gordeev <lasaine@....cs.msu.su>
Cc:	linux-kernel@...r.kernel.org,
	"Nikita V. Youshchenko" <yoush@...msu.su>,
	linuxpps@...enneenne.com, john stultz <johnstul@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>, Joonwoo Park <joonwpark81@...il.com>
Subject: Re: [PATCHv3 05/16] pps: access pps device by direct pointer

On Mon, Aug 09, 2010 at 11:53:43AM +0400, Alexander Gordeev wrote:
> 
> Hmm, yes, I see...
> But this is custom problem of only one client. I think it should be
> fixed in place instead of trying to fix it in the subsystem.

I agree with you but I had no luck in doing it in the past... :'(

Maybe you can ask some help to the serial port maintainers or you can
try in pushing the PPS_IRQ_EVENTS solution (see my repository) into
main tree, in fact that solution could resolve two problems at once:

* this one, since we simply read PPS data into an array in RAM, and
* the weak PPS resolution in recording PPS timestamps into normal IRQ
* handlers.

However, the big issue on this solution is about the call of
gettimeofday() for each IRQs into the system (see old mails into this
list about this topic) which slows down the machine's performance.

A workaround (as suggested by Alan Cox if I well remember) could be
adding a flag for each IRQs in order to know if the timestamp must be
recorded or not (testing a flag is not a bit issue for the machine's
performance).

> Are you 100% sure dcd_change can be called before open or after close?
> Then I'll try to deal with this.

Before the open there are no problems since the line discipline is
off, the problem is during the close.

> > > affects performance. So we have to choose what is the priority:
> > > security or performance. My guru told me I shouldn't bother too much
> > > about broken kernel-space code which my code interacts with. If it's
> > > broken it should be fixed. Some assertions enabled by DEBUG define are
> > > enough. For me it makes sense but I don't know what should I check here?
> > 
> > I'm sorry but I disagree with you. Kernel code can't allow userland
> > programs to corrupt it!
> > 
> > We are not discussing about security or performance but about
> > reliability.
> 
> Sure, now I see the problem (in the pps-ldisc).

Yes, the problem is there (and globally in all drivers whose not
directly take care off PPS issues). Unluckely the pps-ldisc is the
most currently used by PPS users...

Ciao,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail: giometti@...eenne.com
Linux Device Driver                          giometti@...ux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti
Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it
--
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/