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

Date:	Fri, 11 Apr 2008 17:57:40 +0200
From:	Clemens Ladisch <clemens@...isch.de>
To:	Dimitri Gorokhovik <dimitri.gorokhovik@...com.fr>
CC:	tglx@...utronix.de, linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH] HPET: register additional counter-only char device

Dimitri Gorokhovik wrote:
> On Fri, 2008-04-11 at 15:20 +0200, Clemens Ladisch wrote:
> > Dimitri Gorokhovik wrote:
> > > I need to have many processes all reading from userspace the counter register
> > > of the (same) HPET hardware.  [...]
> > > What would be the right way to implement such a support? For now, I simply
> > > register a new misc device, '/dev/hpetctr', along with '/dev/hpet', for the same
> > > ACPI device and on the same occasion.
> >
> > Your patch circumvents CONFIG_HPET_MMAP.
>
> Right. I hesitated to put it in, but multiple #ifdef/endif clutter too
> much the resulting code. Something better should be devised in this
> case, like separating the added code into another file, changing a
> couple of symbols from static to extern etc.
>
> However, why people wanted the original 'mmap' of /dev/hpet to be
> disabled? Probably to prevent the HPET registers from poking with?

Reading HPET registers should not be dangerous in any way, but it might
be possible to read other devices' registers that happen to lie inside
the same memory page (HPET registers are only 1024 bytes).

> > Another possibility would be to allow the device to be opened
> > infinitely many times but not to allocate a hardware timer until one of
> > the ioctls is called.  This means that opening /dev/hpet does not
> > guarantee that a timer is available, but this has already been possible
> > previously because request_irq() might fail.
>
> Good point. The patch would be much more intrusive and voluminous (and
> coming from a total newcomer). Would there be an interest for such a
> patch?

Yes, definitely.  I've wanted to do this patch for some time but haven't
found the time.

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


Regards,
Clemens
--
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/