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: <20111205151643.0c06eddc@lxorguk.ukuu.org.uk>
Date:	Mon, 5 Dec 2011 15:16:43 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	HoP <jpetrous@...il.com>
Cc:	Florian Fainelli <f.fainelli@...il.com>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Andreas Oberritter <obi@...uxtv.org>,
	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?

> You know - I'm a bit confused. Somebody are pointing on double
> data copying (userspace networked daemon -> kernel -> application)
> issue and another one warn me to not start network connection
> from the kernel. But if it works for NFS or CIFS then it should not
> be so weaky, isn't it?

And then you want to add multicast, or SSL or some other transport layer,
and so on. You can do it - but in the case of DVB it's really probably
not the overall way to go.

> What exactly vtuner aproach does so hackish (other then exposing
> DVB internals, what is every time made if virtualization support is developing)?

Exposing DVB internals is also not good - it creates an API which locks
out future trivial changes to that API because it might break your
stuff. Also you are trying to fake distributed network in the wrong place
so faking basically synchronous interfaces with undefined network
behaviour and time lines.

> The code itself no need to patch any line of vanilla kernel source, it even
> doesn't change any processing of the rest of kernel, it is very simple
> driver/code/whatever.

That's not a measure of whether something is a good idea, more of the
cleanness of the core code.

Fix the userspace bits that need fixing, or use ones that don't - in the
longer term that will be a bigger win by far.

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