linux-kernel - Re: [RFC][PATCH] HPET: register additional counter-only char device

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: <1208097653.8038.36.camel@laphroaig>
Date:	Sun, 13 Apr 2008 16:40:53 +0200
From:	Dimitri Gorokhovik <dimitri.gorokhovik@...com.fr>
To:	Clemens Ladisch <clemens@...isch.de>
Cc:	tglx@...utronix.de, linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH] HPET: register additional counter-only char device

On Fri, 2008-04-11 at 17:57 +0200, Clemens Ladisch wrote: 
> Dimitri Gorokhovik wrote:
> > 
> > -- to me, /dev/hpet is primarily a timer, not just a counter. It seems
> > wrong to me if it, once opened, would mostly fail to its primary
> > function (but this of course is all subjective matter).
> 
> There are at least as many available timers as before the change -- a
> program that tries to use a timer will still get a timer, and now this
> will succeed even if there are other programs that use only the counter.
> 
> Even now, for most programs using /dev/hpet, it actually is just a
> counter.

The problem with the implementation of this approach is the multiple hw
instrances of HPET, which is currently supported. Unless one can rip it
all off and hardwire '/dev/hpet' to a single HPET hardware block (can
one ?), I can't seem to figure out how to implement the proposed
modification.

An example:

-- an application opens '/dev/hpet'. There are several HPET hw blocks
in the system -- physical address of some of them is used -- success is
returned. A hw timer slot is not allocated at this point.

-- the app 'mmap's the opened device (the phys address selected in the
'open' is used).

-- some time later, the app issues an 'ioctl' call -- it wants the
interrupt enabled and so a hw timer slot has to be allocated.

It appears that there are no timers available on the hw block whose phys
addr has been used for open/mmap, but there are free timers on the
other(s) HPET hw blocks.

Our choice:
a) 'ioctl' should fail;
b) 'ioctl' may return a timer from another hw block.

I think b) is fundamentally broken. a) risks to return too many failures
with timer slots still available, unless some strategy is devised for
distribution of 'open's across the hw blocks.

Now imagine HPET hw blocks are not created equal in the system (most
likely, clocking frequency is different). What would be such a strategy
in this case ?

All this yields a complex implementation without a real reason (many
(most?) systems with only one HPET hw block), and still a problematic
user interface (how does one chooses the HPET block he or she wants?),
only in the name of the compatibility with the existing interface.

The clean interface would be to have:

/dev/hpet0/counter
          /timer0
          /timer1
          /timer2
	  /...

[/dev/hpet1/...]

'counter' device allowing 'mmap' and 'ioctl(HPET_INFO)', and timer
devices allowing rest of IOCTLs and other fops except mmap. Choosing a
suitable HPET hw is a policy belonging in the app -- right now it is in
the kernel, even thought it is as simple as walking a list.

But then again, such implementation would break the existing interface.

Regards,

Dimitri

--
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/