From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 9 23:27:02 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C482316A403; Mon, 9 Oct 2006 23:27:02 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1DC943D73; Mon, 9 Oct 2006 23:26:51 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (lv0lwfype3j3xm72@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k99NQoPe001238; Mon, 9 Oct 2006 16:26:50 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k99NQoqs001237; Mon, 9 Oct 2006 16:26:50 -0700 (PDT) (envelope-from jmg) Date: Mon, 9 Oct 2006 16:26:50 -0700 From: John-Mark Gurney To: Jonathan Chen Message-ID: <20061009232649.GT793@funkthat.com> Mail-Followup-To: Jonathan Chen , freebsd-hackers@freebsd.org References: <20061009213733.GC15088@porthos.spock.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061009213733.GC15088@porthos.spock.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-hackers@freebsd.org Subject: Re: bktr(4) risk? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2006 23:27:02 -0000 Jonathan Chen wrote this message on Mon, Oct 09, 2006 at 17:37 -0400: > While trying to resurrect meteor(4), I've been looking over the bktr > driver. It seems that the bktr driver implements the METEORSVIDEO ioctl, > which appears to allow userland programs to specify a physical memory > address to which the bktr hardware should dump it's output. At first Yes, it does... > glance, this seems like a rather bad idea, as this would allow anyone armed > with the bktr file descriptor to arbitrarily trash any memory, and the bktr > device comes with a friendly default permission of 0444. > > The only reason I can think of to use this ioctl would be if you wanted the > image you're capturing to be directly dumped into video memory. This This is very common... It allows the bktr driver to dump the frames directly to the memory of your video card... This makes watching live tv watchable... > doesn't seem too useful a task for a video capture card to be doing. > Perhaps we should put a test for write access in there or just eliminate > the ioctl altogether. It should be noted that the meteor driver had this > ioctl ifdef'ed out prior to its removal. Hmmm... I think I'll go ahead and put in a compatibility ioctl based on the way I did the zoran driver, and schedule the removal of the ioctl.. > Disclaimer: I don't have access to a bktr myself, nor am I very familiar > with the intricacies of DMA, so someone with the expertise or the hardware > should check my reasoning or test an exploit before panicing. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."