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: <CAHFNz9JqrtfvEmgoPeWG3kLAzrqZes9J3yHrAoJG-_JLUuTBcQ@mail.gmail.com>
Date:	Tue, 6 Dec 2011 21:06:14 +0530
From:	Manu Abraham <abraham.manu@...il.com>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Andreas Oberritter <obi@...uxtv.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, HoP <jpetrous@...il.com>,
	Florian Fainelli <f.fainelli@...il.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 Tue, Dec 6, 2011 at 8:36 PM, Mauro Carvalho Chehab
<mchehab@...hat.com> wrote:
> On 06-12-2011 12:38, Andreas Oberritter wrote:
>>
>> On 06.12.2011 15:13, Mauro Carvalho Chehab wrote:
>>>
>>> O_NONBLOCK
>>>     When opening a FIFO with O_RDONLY or O_WRONLY set:
>>
>>                      ^^^^ This does not apply.
>>
>> [...]
>>
>>>     When opening a block special or character special file that supports
>>> non-blocking opens:
>>>
>>>         If O_NONBLOCK is set, the open() function shall return without
>>> blocking for the device to be ready or available. Subsequent behavior of
>>> the device is device-specific.
>>
>>
>> This is the important part:
>> - It specifies the behaviour of open(), not ioctl(). I don't see a
>> reason why open should block with vtunerc.
>> - Read again: "Subsequent behavior of the device is device-specific."
>>
>>>         If O_NONBLOCK is clear, the open() function shall block the
>>> calling thread until the device is ready or available before returning.
>>>
>>>     Otherwise, the behavior of O_NONBLOCK is unspecified.
>>>
>>> Basically, syscall should not block waiting for some data to be read (or
>>> written).
>>
>>
>> That's because open() does not read or write.
>>
>>> The ioctl definition defines [EAGAIN] error code, if, for any reason, an
>>> ioctl would block.
>>
>>
>> Fine.
>>
>>> Btw, the vtunerc doesn't handle O_NONBLOCK flag. For each DVB ioctl, for
>>> example
>>> read_snr[1], it calls wait_event_interruptible()[2], even if the
>>> application opens
>>> it with O_NONBLOCK flag. So, it is likely that non-blocking-mode
>>> applications
>>> will break.
>>
>>
>> Of course, read operations must wait until the value read is available
>> or an error (e.g. timeout, i/o error) occurs. Whether it's an i2c
>> transfer, an usb transfer or a network transfer doesn't make a
>> difference. Every transfer takes a nonzero amount of time.
>
>
> Yes, posix is not 100% clear about what "non block" means for ioctl's, but
> waiting for an event is clearly a block condition. This is different than
> doing something like mdelay() (or even mleep()) in order to wait for an
> specific amount of time for an operation to complete.
>
> A vtunerc => daemon => network transfer =>daemon => vtunerc is a block
> condition,
> as the network may return in a few ms or may not return and a long
> timeout at the daemon would give an error. Also, as the daemon may be
> swapped
> to disk (as the daemon runs on userspace), this may even involve other
> blocking operations at the block layer.
>
>
>> As Honza already demonstrated, in a typical LAN setup, this takes only
>> few milliseconds, which with fast devices may even be faster than some
>> slow local devices using many delays in their driver code.
>>
>> If an application breaks because of that, then it's a bug in the
>> application which may as well be triggered by a local driver and thus
>> needs to be fixed anyway.
>
>
> It is not a bug in the application. It requested a non-block mode. The
> driver
> is working in block mode instead. It is a driver's bug.
>
>
>>>> Mauro, if the network is broken, any application using the network will
>>>> break. No specially designed protocol will fix that.
>>>
>>>
>>> A high delay network (even a congested one) is not broken, if it can
>>> still provide the throughput required by the application, and a
>>> latency/QoS
>>> that would fit.
>>
>>
>> Then neither vtunerc nor any other application will break. Fine.
>>
>>>> If you want to enforce strict maximum latencies, you can do that in the
>>>> userspace daemon using the vtunerc interface. It has all imaginable
>>>> possibilities to control data flow over the network and to return errors
>>>> to vtunerc.
>>>
>>>
>>> Yes, you can do anything you want at the userspace daemon, but the
>>> non-userspace daemon aware applications will know nothing about it, and
>>> this is the flaw on this design: Applications can't negotiate what
>>> network
>>> parameters are ok or not for its usecase.
>>
>>
>> How do you negotiate network parameters with your ISP and all involved
>> parties on the internet on the way from your DSL line to some other
>> peer? Let me answer it: You don't.
>
>
> TCP flow control mechanisms, RSVP, MPLS, IP QoS flags, ICMP messages, etc.
>

You would need a Data Link Protocol, which would be PPP of some form

http://en.wikipedia.org/wiki/Point-to-Point_Protocol

I don't think, you have much to negotiate there.

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