Date: Fri, 21 Mar 1997 15:18:45 -0800 From: Amancio Hasty <hasty@rah.star-gate.com> To: "Louis A. Mamakos" <louie@TransSys.COM> Cc: Steve Passe <smp@csn.net>, hackers@freebsd.org, Michael Petry <petry@netwolf.NetMasters.com>, multimedia@freebsd.org Subject: Re: Continquous Memory vs Virtual Memory Message-ID: <199703212318.PAA02970@rah.star-gate.com> In-Reply-To: Your message of "Fri, 21 Mar 1997 17:59:21 EST." <199703212259.RAA09791@whizzo.transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>From The Desk Of "Louis A. Mamakos" :
> > 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
Hey Louie, don't be shy to post to the hackers list. They are there for
this sort of questions 8)
To hackers,
Is there an easy way for me to determine the actual physical pages that
a kernel malloc returns or should I just go ahead and do it manually.
Thats is translate the virtual memory address to a physical address
across the memory region a kernel malloc returns to a driver.
The background of all this is that the Bt848 video capture chip does
not really require a contiguous memory region since individual
captured lines can be directed to any region by way of a "risc program"
To give you an idea of what we do, here are fragments from the Bt848
driver.
inst = OP_WRITE | OP_SOL | bt_enable_cnt << 12 | (b);
inst2 = OP_WRITE | bt_enable_cnt << 12 | (cols * pixel_width/2);
And in a for loop:
---
*dma_prog++ = inst;
*dma_prog++ = target_buffer;
target_buffer += interlace*pitch;
----
Target_buffer can be any memory location in the host or in a video adapter's
frame buffer.
Tnks,
Amancio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703212318.PAA02970>