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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111203164252.3a66d638@lxorguk.ukuu.org.uk>
Date:	Sat, 3 Dec 2011 16:42:52 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Andreas Oberritter <obi@...uxtv.org>
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?

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

> The original version of the vtuner interface makes use of demux hardware
> and also feeds the relevant streams to a/v decoders, in which case you
> cannot avoid copying the MPEG data to kernel space.

Right and that aspect of it actually makes a lot more sense to me,
because receive and decode/playback are different functional units.

But jumping up and down arguing about how you want to name the code isn't
going to produce a productive result

To answer the other question posed by "HoP" - yes you can do TCP from
kernel space. We need this for things like NFS, CIFS etc. That might well
be valuable especially for low end hardware. The best code to read is
probably the net/sunrpc code to get an idea of how it ends up looking.

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/