From owner-freebsd-multimedia Tue Nov 4 00:37:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA24318 for multimedia-outgoing; Tue, 4 Nov 1997 00:37:22 -0800 (PST) (envelope-from owner-freebsd-multimedia) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA24310 for ; Tue, 4 Nov 1997 00:37:19 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id AAA00548; Tue, 4 Nov 1997 00:31:19 -0800 (PST) Message-Id: <199711040831.AAA00548@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Luigi Rizzo cc: multimedia@freebsd.org Subject: Re: A small addition to the bt848 driver... In-reply-to: Your message of "Tue, 04 Nov 1997 07:42:56 +0100." <199711040642.HAA19393@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Nov 1997 00:31:19 -0800 From: Amancio Hasty Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > In any case if you are so worried about misuse of the card, you should > > > really restrict access to it. As it is now, it is perfectly possible > > > that some user passes a bogus video.addr to the card instructing > > > it to dump data onto memory at random places ? There is no checking > > > whatsoever... That's in my opinion a big security hole. > > > > Passing whatever address you want to the bt848 is not a security > > hole if people are so concerned about it then just add appropiate > > permissions to /dev/bktr* . > > precisely my point (however maybe something could be done in the > driver to check at least that the "video.addr" does not point to > pages of non-video RAM). Nope I rather keep this way for the purpose of future usage like dumping video straight to a memory mapped region of a device other than a video card. > > Typically Luigi, if it is for development the code is wrapped around > > a #ifdef ;however, if you feel like you have a genuine usage for > > your ioctl then I will be happy to have them committed. > > whatever you like. I think this will let us write user-space apps to > control the tuner, teletext circuitry and so on. This can be a > significant advantage even for non-developers who will not have to > rebuild the kernel to upgrade. > Fine then please just check in the code for controlling the tuner. Tnks, Amancio