Re: VIA command verifier.
Hi. On Maw, 2004-11-30 at 20:09, Thomas Hellström wrote: Textures in AGP memory is currently not allowed, but they are disabled in the Mesa driver as well, for some reason. If they are allowed in the future, Texture address checks probably have to be implemented but that should be a minor task. I certainly turned them off because they were crashing my box in the original hey it sort of works codebase. I don't know if its that or if someone did more work on it later. I managed to get AGP textures working after some extra return-value checking. At least it seems rather stable, so I implemented a texture address check in the verifier, which checks that the texture is actually fetched from a client-drm-mapped memory region. System memory textures are still rejected. So unless someone has anything against this, I'll check it in in the via drm driver, and put up a modified unichrome_dri.so on the unichrome site for some serious beta-testing. Possibly also with different user command buffer sizes. /Thomas --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VIA command verifier.
Thomas Hellström wrote: Hi. On Maw, 2004-11-30 at 20:09, Thomas Hellström wrote: Textures in AGP memory is currently not allowed, but they are disabled in the Mesa driver as well, for some reason. If they are allowed in the future, Texture address checks probably have to be implemented but that should be a minor task. I certainly turned them off because they were crashing my box in the original hey it sort of works codebase. I don't know if its that or if someone did more work on it later. I managed to get AGP textures working after some extra return-value checking. At least it seems rather stable, so I implemented a texture address check in the verifier, which checks that the texture is actually fetched from a client-drm-mapped memory region. System memory textures are still rejected. So unless someone has anything against this, I'll check it in in the via drm driver, and put up a modified unichrome_dri.so on the unichrome site for some serious beta-testing. Possibly also with different user command buffer sizes. /Thomas --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel Great Thomas, Where is the source/patches for the DRM/3D driver? I will update my Fedora RPMS and try it out ... Cheers Terry -- Dr Terry Barnaby BEAM Ltd Phone: +44 1454 324512 Northavon Business Center, Dean Rd Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK Email: [EMAIL PROTECTED] Web: www.beam.ltd.uk BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software Dev Tandems are twice the fun ! --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VIA command verifier.
On Maw, 2004-11-30 at 20:09, Thomas Hellström wrote: Textures in AGP memory is currently not allowed, but they are disabled in the Mesa driver as well, for some reason. If they are allowed in the future, Texture address checks probably have to be implemented but that should be a minor task. I certainly turned them off because they were crashing my box in the original hey it sort of works codebase. I don't know if its that or if someone did more work on it later. Nope, doesn't look like that from a quick glance. But there are obvious bugs in the texture memory allocation since the code fails to check properly that the allocation succeeded. The verifier is reasonably fast. It lowers the glxgears frame-rate a percent or two. However if it operates directly on AGP memory, it's a _real_ performance killer. So the userspace command buffer should be copied to kernel (static) system memory, checked and then copied again to the AGP ring-buffer. That should be fine if the command buffers are not too large ( 64K or so) because they will be cached for the two passes. Actually, I've been running with a 512Kb userspace / kernel buffer, and I've not seen any noticable drop in performance, but I'm not sure that the submissions actually will be that large with the programs I've tested. If the perfomance drop I experience with running the verifier on AGP memory is due to the fact that none of it is previously cached or that the processor cannot cache WC memory lines while reading? If it is due to the latter then we should be OK with large cacheable buffers. Otherwise we will run into trouble when the buffer does not fit in the cache. Comments are appreciated, particularly on the security assumptions and whether something doesn't fit well into the DRM coding style. Only real comment is that it would be better if the tables were pre-initialized. gcc has some extensions for just specifying bits of an array that might do this. Thats really it. I planned to have the tables initialized as part of the module initialization, so it will never depend on an external master process initializing them, and there will be no chance of someone doing anything nasty before the verifier is initialized. I believe it's good for readability to have the command index right beside the intended action, and it will also be easier to extend / modify the code in this way. Thanks for the comments. /Thomas. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VIA command verifier.
On Mer, 2004-12-01 at 12:19, Thomas Hellstrm wrote: Actually, I've been running with a 512Kb userspace / kernel buffer, and I've not seen any noticable drop in performance, but I'm not sure that the submissions actually will be that large with the programs I've tested. Might be worth finding the size needed - remembering a 512K buffer can be verified and copied in 32K chunks anyway. If the perfomance drop I experience with running the verifier on AGP memory is due to the fact that none of it is previously cached or that the processor cannot cache WC memory lines while reading? If it is due to the latter then we should be OK with large cacheable buffers. Otherwise we will run into trouble when the buffer does not fit in the cache. AGP space is uncached. We could pull the pages out of AGP, write to them and put them back but we don't really support that right now. As a result all I/O to AGP pages is strictly synchronous. Pulling stuff from cachable memory and verifying it will prefetch lines from memory on the later processors (and you can also hint this with the prefetch(address) call in the kernel (prefetch about 320 bytes ahead is normally right). I'd expect the user pages are already in L2 cache anyway from when Mesa wrote the bits. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
VIA command verifier.
Hi!
I've put together a DMA command verifier for the VIA drm. It restricts
access to DMA registers and system and AGP memory while 3D commands and
2D / Mpeg is allowed to pass.
Currently frame-buffer memory is considered all authenticated client's
property, but I've added provisions to check destination and z-buffer
memory addresses, but that would require some interoperation with the
via DRM memory manager. Since the frame-buffer is read-write this
currently is an overkill.
Textures in AGP memory is currently not allowed, but they are disabled
in the Mesa driver as well, for some reason. If they are allowed in the
future, Texture address checks probably have to be implemented but that
should be a minor task.
The verifier is reasonably fast. It lowers the glxgears frame-rate a
percent or two. However if it operates directly on AGP memory, it's a
_real_ performance killer. So the userspace command buffer should be
copied to kernel (static) system memory, checked and then copied again
to the AGP ring-buffer.
The file can be directly compiled in with the Mesa driver as well since
that makes debugging a lot easier.
Not all 3D functionality is in, but it is a start and it apparently
works ok with the current Mesa unichrome driver. I've tested glxgears,
chromium, tuxracer and the GL xscreensavers.
Comments are appreciated, particularly on the security assumptions and
whether something doesn't fit well into the DRM coding style.
/Thomas
/*
* Copyright 2004 The Unichrome Project. All Rights Reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the Software),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sub license,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the
* next paragraph) shall be included in all copies or substantial portions
* of the Software.
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
* THE UNICHROME PROJECT, AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
* OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
* ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
* DEALINGS IN THE SOFTWARE.
*
* Author: Thomas Hellström 2004.
* This code was written using docs obtained under NDA from VIA Inc.
*/
#include via_3d_reg.h
#ifndef __KERNEL__
/*
* For debugging purposes
*/
#include stdio.h
#include errno.h
typedef unsigned uint32_t;
#define DRM_ERROR(fmt, arg...) fprintf(stderr, fmt, ##arg)
#define DRM_DEBUG(fmt, arg...) printf(fmt, ##arg)
#define DRM_ERR(arg) -(arg)
#else
#include via.h
#include drmP.h
#endif
typedef enum{
state_command,
state_header2,
state_header1,
state_error
} verifier_state_t;
typedef enum{
no_sequence = 0,
z_address,
dest_address,
tex_address
}sequence_t;
typedef enum{
no_check = 0,
check_for_header2,
check_for_header1,
check_for_header2_err,
check_for_header1_err,
check_for_fire,
check_z_buffer_addr,
check_z_buffer_addr_mode,
check_destination_addr,
check_destination_addr_mode,
check_for_dummy,
check_for_dd,
check_texture_addr,
check_texture_addr_mode,
forbidden_command
}hazard_t;
/*
* Associates each hazard above with a possible multi-command
* sequence. For example and address that is split over multiple
* commands and needs to be checked at the first command that does
* not include any part of the address.
*/
static sequence_t seqs[] =
{ no_sequence,
no_sequence,
no_sequence,
no_sequence,
no_sequence,
no_sequence,
z_address,
z_address,
dest_address,
dest_address,
no_sequence,
no_sequence,
tex_address,
tex_address,
no_sequence
};
typedef struct{
unsigned int code;
hazard_t hz;
} hz_init_t;
static hz_init_t init_table1[] =
{{0xf2, check_for_header2_err},
{0xf0, check_for_header1_err},
{0xee, check_for_fire},
{0xcc, check_for_dummy},
{0xdd, check_for_dd},
{0x00, no_check},
{0x10, check_z_buffer_addr},
{0x11, check_z_buffer_addr},
{0x12, check_z_buffer_addr_mode},
{0x13, no_check},
{0x14, no_check},
{0x15, no_check},
{0x23, no_check},
{0x24, no_check},
{0x33, no_check},
{0x34, no_check},
{0x35, no_check},
{0x36, no_check},
{0x37, no_check},
{0x38, no_check},
{0x39, no_check},
{0x3A, no_check},
{0x3B, no_check},
{0x3C, no_check},
{0x3D, no_check},
{0x3E, no_check},
{0x40, check_destination_addr},
{0x41, check_destination_addr},
{0x42,
Re: VIA command verifier.
On Maw, 2004-11-30 at 20:09, Thomas Hellstrm wrote: Textures in AGP memory is currently not allowed, but they are disabled in the Mesa driver as well, for some reason. If they are allowed in the future, Texture address checks probably have to be implemented but that should be a minor task. I certainly turned them off because they were crashing my box in the original hey it sort of works codebase. I don't know if its that or if someone did more work on it later. The verifier is reasonably fast. It lowers the glxgears frame-rate a percent or two. However if it operates directly on AGP memory, it's a _real_ performance killer. So the userspace command buffer should be copied to kernel (static) system memory, checked and then copied again to the AGP ring-buffer. That should be fine if the command buffers are not too large ( 64K or so) because they will be cached for the two passes. Not all 3D functionality is in, but it is a start and it apparently works ok with the current Mesa unichrome driver. I've tested glxgears, chromium, tuxracer and the GL xscreensavers. I'd rather it under than overpermitted things too. Comments are appreciated, particularly on the security assumptions and whether something doesn't fit well into the DRM coding style. Only real comment is that it would be better if the tables were pre-initialized. gcc has some extensions for just specifying bits of an array that might do this. Thats really it. Looks good --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
