linux-kernel - Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

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]

Message-ID: <4EDA5E98.4080205@linuxtv.org>
Date:	Sat, 03 Dec 2011 18:38:32 +0100
From:	Andreas Oberritter <obi@...uxtv.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	HoP <jpetrous@...il.com>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because
 of worrying about possible misusage?

On 03.12.2011 17:42, Alan Cox wrote:
>> FWIW, the virtual DVB device we're talking about doesn't have any
>> networking capabilities by itself. It only allows to create virtual DVB
>> adapters and to relay DVB API ioctls to userspace in a
>> transport-agnostic way.
> 
> Which you can do working from CUSE already, as has been pointed out or
> with LD_PRELOAD. This btw makes the proprietary thing seem a rather odd
> objection - they could do it too.

Yes, both CUSE and LD_PRELOADED have already been suggested. But I
already explained in previous mails why both options are unsuitable:

- For LD_PRELOAD to intercept any calls to open, ioctl, read, write, the
character device to be intercepted must exist first. But it doesn't
exist, unless it was created by vtuner first. Of course you could also
intercept stat(), readdir() and all other possible functions to list or
access devices and fake entries, but I hope you're not suggesting this
seriously. Well, proprietary drivers doing that already exist today
(e.g. by sundtek), but implementing somthing like that if an easier
solution is possible would be crazy at best.

Additionaly, preloaded libraries conflict with other preloaded libraries
overwriting the same functions. Preloaded libraries don't work with
statically linked programs. Preloaded libraries can't be used
transparently, because you need to edit init scripts to use them, unless
you want them to be used globally (in /etc/ld.so.preload).

- CUSE would conflict with dvb-core. Once CUSE created a DVB adapter,
registering another non-virtual DVB adapter (by plugging in a USB device
for example) will try to assign the same adapter number.

The following only applies to the original version of the interface, but
is likely to apply to future development of the proposed interface: In
order to add virtual tuners to existing DVB adapters, to be able to use
their hardware demux or MPEG decoders with CUSE, the whole device driver
of this adapter has to be implemented in userspace.

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