From owner-freebsd-multimedia Fri Mar 21 14:59:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA20215 for multimedia-outgoing; Fri, 21 Mar 1997 14:59:46 -0800 (PST) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA20210 for ; Fri, 21 Mar 1997 14:59:38 -0800 (PST) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.8.5/8.7.3) with SMTP id RAA09791; Fri, 21 Mar 1997 17:59:22 -0500 (EST) Message-Id: <199703212259.RAA09791@whizzo.transsys.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Steve Passe cc: Amancio Hasty , Michael Petry , multimedia@freebsd.org From: "Louis A. Mamakos" Subject: Re: Continquous Memory vs Virtual Memory References: <199703212214.PAA25609@Ilsa.StevesCafe.com> In-reply-to: Your message of "Fri, 21 Mar 1997 15:14:06 MST." <199703212214.PAA25609@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Mar 1997 17:59:21 -0500 Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hi, > > > Nope, because the risc program is build in a allocated area in > > the kernel which the user can't override. If someone wanted > ^^^^^^^^^^^^^^^^^ > > to over-write a particular region of memory with the output > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > of the bt848 , they can . > ^^^^^^^^^^^^^^^^^^^^^^^^^ > > this is the possibility that I was refering to. thus they could do the > same thing that people do with strcpy(), write a short segment of > code that creates a "worm hole" into the kernel, then install it > with the above technique. this says to me that allowing a user > to create and load a RISC program is a BAD idea. But having the > kernel level RISC compiler is a good idea. It could enforce that the > destination address MUST be within the range of the video card's > linear buffer. Now we still need to worry about source addresses, > a clever programmer could write a "snoop" program that > could look into kernel core for other hacking info... You need to do something a bit different than this. I'm also presuming that you'd want to capture into a memory buffer that the user's got access to, rather than just into a frame buffer. I think that you'd still want to support clipping regions, as all the effort had already been done to accomodate the frame buffer. The cool part here is that the (real) memory need not be continguous, meaning that any old buffer that the user malloc()'ed could be used, provided that it's actually in a resident page frame. I fear that more knowledge of the VM system is going to be necessary.. Oh boy. louie