On 2002.03.02 23:02 Keith Whitwell wrote:
>
> > > To do that in a secure manner, these commands should be either
> verified or
> > > even written by the DRM. A good way to do this would be have a
> template in
> > > the DRM for generating a set of functions for each of those generated
> by
> > > t_dd_vbtmp.h. (If this idea is viable, while DMA is not enabled in
> the
> > > DRM, this could be initialy implemented with a pseudo DMA software
> alike
> > > approach, as Leif suggested, and we could could guarantee security
> from
> > > the start.)
> >
> > Or do the d3d-to-mach64 vertex translation in the kernel? Or is this
> exactly
> > what you are suggesting???
>
I was also trying to avoid the extra translation. I would to add the
commands in-place. See below.
> Just to make things clear, I think this is an excellent idea. Having the
> mach64 emulate a d3d-like device allows you to leverage all the good
> optimizations we've found for this type of device, have a relatively
> normal &
> sane looking driver, and get security by doing all the nasty command
> stuff in
> the kernel.
>
> Thus the simplest ioctl struct would look like:
>
> struct {
> const char *d3d_vertices;
> int vertex_format;
> int primitive;
> int vertex_count;
> };
>
> Vertex size can be derived from vertex_format & vertex_count.
>
> Keith
>
It would be a structure quite similar to that, the only difference would
be that it would not have a d3d format. The buffer would instead include
the placeholders to the commands. e.g, to draw a vertex of a triangle, the
vertex buffer would be:
0000: 00000000 /* placeholder for a command */
0004: ???????? /* VERTEX_1_S */
0008: ???????? /* VERTEX_1_T */
000c: ???????? /* VERTEX_1_W */ 0010: ???????? /*
VERTEX_1_SPEC_ARGB */
0014: ???????? /* VERTEX_1_Z */ 0018: ???????? /*
VERTEX_1_ARGB */
001c: ???????? /* VERTEX_1_XY */
0020: 00000000 /* placeholder for a command */
0024: ???????? /* VERTEX_1_SECONDARY_S */
0028: ???????? /* VERTEX_1_SECONDARY_T */
002c: ???????? /* VERTEX_1_SECONDARY_W */ 0030:
... /* the same as above for vertex 2, 3, and so on */
Note: This was based on mach64tri.c of Utah-GLX
The DRM would unmap this buffer to prevent further tampering, and it would
then add the commands:
0000: (MACH64_VERTEX_1_S) | (6<<16) /* setup for programming seven
sequential registers */
0004: ???????? /* VERTEX_1_S */
0008: ???????? /* VERTEX_1_T */
000c: ???????? /* VERTEX_1_W */ 0010: ???????? /*
VERTEX_1_SPEC_ARGB */
0014: ???????? /* VERTEX_1_Z */ 0018: ???????? /*
VERTEX_1_ARGB */
001c: ???????? /* VERTEX_1_XY */
0020: (MACH64_VERTEX_1_SECONDARY_S) | (2<<16) /* setup for programming
three sequential registers */
0024: ???????? /* VERTEX_1_SECONDARY_S */
0028: ???????? /* VERTEX_1_SECONDARY_T */
002c: ???????? /* VERTEX_1_SECONDARY_W */ 0030: ...
Since as in _vb.c, the format of the vertex buffer varies, there would
have to be an equivalent DRM function for each *_emit_*. This doesn't mean
there must be an ioctl for each one too - a setup/callback mechanism would
suffice. (It could be even attempted to make a single template for both
the DRI driver and DRM, which behavior would be controlled by a definition
- but this isn't the issue.)
As far as I can see this would be secure, assuming that invalid data
couldn't cause by itself security problems. If this assumption isn't true,
then an extra check or data bitmasking would be necessary.
To this be efficient the (un)map must be quick too. I really don't know
about that, but since this is used in other drivers (such as i810), I
guess it must be. If's not then, instead of doing it in-place, the DRM
would copy as it would write the commands and check the data. It would be
rather similar with that you proposed then, but notice that the vertex
structure format wouldn't be the same as d3d.
This deals with vertexs only, but similar schemes could be made for other
kind of commands (texture setups, etc), even more easily since they don't
come in so many shapes as the vertexes do.
José Fonseca
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
