- 18 11月, 2010 2 次提交
-
-
由 Alex Deucher 提交于
Looks like a typo in: drm/radeon/r600: fix tiling issues in CS checker. (f30df2fa) Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Tiled buffers have the same alignment requirements regardless of whether the surface is for db, cb, or textures. Previously, the calculations where inconsistent for each buffer type. - Unify the alignment calculations in a common function - Standardize the alignment units (pixels for pitch/height/depth, bytes for base) - properly check the buffer base alignments Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 28 10月, 2010 1 次提交
-
-
由 Alex Deucher 提交于
Calculate height based on the slice bitfield rather than the size. Same as Dave's CB fix. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 27 10月, 2010 1 次提交
-
-
由 Alex Deucher 提交于
broken by: drm/radeon/r600: fix tiling issues in CS checker. v2: only apply it to 1D tiling case. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 26 10月, 2010 2 次提交
-
-
由 Alex Deucher 提交于
macro tile heights are aligned to num channels, not num banks. Noticed by Dave Airlie. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Cc: stable@kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
The CS checker had some incorrect alignment requirements for 2D surfaces, this made rendering to mipmap levels that were 2D broken. Also the CB height was being worked out from the BO size, this doesn't work at all when rendering mipmap levels, instead we work out what height userspace wanted from slice max and use that to check it fits inside the BO, however the DDX send the wrong slice max for an unaligned buffer so we have to workaround for that even though its a userspace bug. Reviewed-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 15 9月, 2010 1 次提交
-
-
由 Alex Deucher 提交于
The texture base address registers are in units of 256 bytes. The original CS checker treated these offsets as bytes, so the original check was wrong. I fixed the units in a patch during the 2.6.36 cycle, but this ended up breaking some existing userspace (probably due to a bug in either userspace texture allocation or the drm texture mipmap checker). So for now, until we come up with a better fix, just warn if the mipmap size it too large. This will keep existing userspace working and it should be just as safe as before when we were checking the wrong units. These are GPU MC addresses, so if they fall outside of the VRAM or GART apertures, they end up at the GPU default page, so this should be safe from a security perspective. v2: Just disable the warning. It just spams the log and there's nothing the user can do about it. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Cc: Jerome Glisse <glisse@freedesktop.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 12 8月, 2010 2 次提交
-
-
由 Dave Airlie 提交于
This never really got fixed in mesa, and the kernel deals with the problem just fine, so don't got reporting things that confuse people. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
add default case for buffer formats Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Cc: Andre Maasikas <amaasikas@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 10 8月, 2010 1 次提交
-
-
由 Alex Deucher 提交于
- buffer offsets in the base regs are 256b aligned so shift properly when comparing, fixed by Andre Maasikas - mipmap size was calculated wrong when nlevel=0 - texture bo offsets were used after the bo base address was added - vertex resource size register is size - 1, not size Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Cc: Andre Maasikas <amaasikas@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 02 8月, 2010 2 次提交
-
-
由 Alex Deucher 提交于
Covers depth, cb, and textures. Hopefully I got this right. v2: - fix bugs: https://bugs.freedesktop.org/show_bug.cgi?id=28327 https://bugs.freedesktop.org/show_bug.cgi?id=28381 - use ALIGNED(), IS_ALIGNED() macros Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Check for relocs for DB_DEPTH_INFO, CB_COLOR*_INFO, and texture resources. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 22 7月, 2010 1 次提交
-
-
由 Dave Airlie 提交于
We only add/remove crtcs at driver load, you cannot remove when the GPU is running a CS packet since the fd is open, when GPU hotplugging on radeons actually is needed all this locking needs a review and I've started re-working kms core locking to deal with this better. But for now avoid long delays in CS processing when hotplug detect is happening in a different thread. this fixes a regression introduced with hotplug detection. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 31 3月, 2010 1 次提交
-
-
由 Alex Deucher 提交于
- Drop some more safe regs taht userspace shouldn't hit - Constant base regs need relocs. This allows us to use constant buffers rather than the constant register file. Also we don't want userspace to be able to set arbitrary mc base values for the const caches. - Track SQ_CONFIG so we know whether userspace is using the cfile or constant buffers. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 18 2月, 2010 1 次提交
-
-
由 Alex Deucher 提交于
drivers/gpu/drm/radeon/r600_cs.c: In function ‘r600_cs_track_check’: drivers/gpu/drm/radeon/r600_cs.c:166: warning: ‘bpe’ may be used uninitialized in this function drivers/gpu/drm/radeon/r600_cs.c:166: note: ‘bpe’ was declared here drivers/gpu/drm/radeon/r600_cs.c: In function ‘r600_cs_parse’: drivers/gpu/drm/radeon/r600_cs.c:938: warning: ‘bpe’ may be used uninitialized in this function drivers/gpu/drm/radeon/r600_cs.c:938: note: ‘bpe’ was declared here Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 12 2月, 2010 1 次提交
-
-
由 Jerome Glisse 提交于
radeon_cs kfree the tracker structure but for r6xx/r7xx we want to kfree it inside the parse function because we share it with the UMS code path. Set tracker to NULL after freeing it will avoid double free. Signed-off-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 11 2月, 2010 1 次提交
-
-
由 Jerome Glisse 提交于
This patch add cs checker to r600/r700 hw. Command stream checking will rewrite some of the cs value in order to restrict GPU access to BO size. This doesn't break old userspace but just enforce safe value. It should break any things that was using the r600/r700 cs ioctl to do forbidden things (malicious software), though we are not aware of such things. Here is the list of thing we check : - enforcing resource size - enforcing color buffer slice tile max, will restrict cb access - enforcing db buffer slice tile max, will restrict db access We don't check for shader bigger than the BO in which they are supposed to be, such use would lead to GPU lockup and is harmless from security POV, as far as we can tell (note that even checking for this wouldn't prevent someone to write bogus shader that lead to lockup). This patch has received as much testing as humanly possible with old userspace to check that it didn't break such configuration. However not all the applications out there were tested, thus it might broke some odd, rare applications. [airlied: fix rules for cs checker for parallel builds] Signed-off-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 25 1月, 2010 1 次提交
-
-
由 Dave Airlie 提交于
This just adds a little more info to the warning for old -ati/mesa userspaces. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 21 1月, 2010 1 次提交
-
-
由 Jerome Glisse 提交于
This patch workaround a possible security issue which can allow user to abuse drm on r6xx/r7xx hw to access any system ram memory. This patch doesn't break userspace, it detect "valid" old use of CB_COLOR[0-7]_FRAG & CB_COLOR[0-7]_TILE registers and overwritte the address these registers are pointing to with the one of the last color buffer. This workaround will work for old mesa & xf86-video-ati and any old user which did use similar register programming pattern as those (we expect that there is no others user of those ioctl except possibly a malicious one). This patch add a warning if it detects such usage, warning encourage people to update their mesa & xf86-video-ati. New userspace will submit proper relocation. Fix for xf86-video-ati / mesa (this kernel patch is enough to prevent abuse, fix for userspace are to set proper cs stream and avoid kernel warning) : http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=95d63e408cc88b6934bec84a0b1ef94dfe8bee7b http://cgit.freedesktop.org/mesa/mesa/commit/?id=46dc6fd3ed5ef96cda53641a97bc68c3bc104a9f Abusing this register to perform system ram memory is not easy, here is outline on how it could be achieve. First attacker must have access to the drm device and be able to submit command stream throught cs ioctl. Then attacker must build a proper command stream for r6xx/r7xx hw which will abuse the FRAG or TILE buffer to overwrite the GPU GART which is in VRAM. To achieve so attacker as to setup CB_COLOR[0-7]_FRAG or CB_COLOR[0-7]_TILE to point to the GPU GART, then it has to find a way to write predictable value into those buffer (with little cleverness i believe this can be done but this is an hard task). Once attacker have such program it can overwritte GPU GART to program GPU gart to point anywhere in system memory. It then can reusse same method as he used to reprogram GART to overwritte the system ram through the GART mapping. In the process the attacker has to be carefull to not overwritte any sensitive area of the GART table, like ring or IB gart entry as it will more then likely lead to GPU lockup. Bottom line is that i think it's very hard to use this flaw to get system ram access but in theory one can achieve so. Side note: I am not aware of anyone ever using the GPU as an attack vector, nevertheless we take great care in the opensource driver to try to detect and forbid malicious use of GPU. I don't think the closed source driver are as cautious as we are. Signed-off-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 23 12月, 2009 1 次提交
-
-
由 Julia Lawall 提交于
Use kzalloc rather than kcalloc(1,...) The use of the allocated memory that looks like an array is &p->relocs[0], but this should be the same as p->relocs. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ @@ - kcalloc(1, + kzalloc( ...) // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 10 11月, 2009 1 次提交
-
-
由 Alex Deucher 提交于
Add some additional regs that require relocs. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 08 10月, 2009 1 次提交
-
-
由 Dave Airlie 提交于
Both r100/r600 had this wrong, use the macro to extract the register to relocate. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 29 9月, 2009 1 次提交
-
-
由 Jerome Glisse 提交于
Convert the rv515 asic support to new init path also add an explanation in radeon.h about the new init path. There is also few cleanups associated with this change (others asic calling rv515 helper functions). Signed-off-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 28 9月, 2009 1 次提交
-
-
由 Dave Airlie 提交于
The legacy r600 path shares code, but doesn't share quite enough to get the freeing correct. Free the pages here also. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 26 9月, 2009 2 次提交
-
-
由 Alex Deucher 提交于
Need add reloc offset to the offset in the actual packet. Fixes use of the DRAW_INDEX packet by the 3D driver. [airlied: modified first one where idx_value == ib[idx+0] Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Alex Deucher 提交于
Provides support for anti-tearing functionality in the ddx. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 25 9月, 2009 2 次提交
-
-
由 Dave Airlie 提交于
this avoids reading back the IB on AGP, also it avoids the race where since we haven't fetched the page from the main IB and written it to the gpu one, reading back fetches 0. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
This avoids needing to do a kmalloc > PAGE_SIZE for the main indirect buffer chunk, it adds an accessor for all reads from the chunk and caches a single page at a time for subsequent reads. changes since v1: Use a two page pool which should be the most common case a single packet spanning > PAGE_SIZE will be hit, but I'm having trouble seeing anywhere we currently generate anything like that. hopefully proper short page copying at end added parser_error flag to set deep errors instead of having to test every ib value fetch. fixed bug in patch that went to list. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 14 9月, 2009 1 次提交
-
-
由 Jerome Glisse 提交于
radeon_share.h was begining to give problem with include order in respect of radeon.h. It's easier and also i think cleaner to move what was in radeon_share.h into radeon.h. At the same time use the extern keyword for function shared accross the module. Signed-off-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 08 9月, 2009 1 次提交
-
-
由 Jerome Glisse 提交于
This adds the r600 KMS + CS support to the Linux kernel. The r600 TTM support is quite basic and still needs more work esp around using interrupts, but the polled fencing should work okay for now. Also currently TTM is using memcpy to do VRAM moves, the code is here to use a 3D blit to do this, but isn't fully debugged yet. Authors: Alex Deucher <alexdeucher@gmail.com> Dave Airlie <airlied@redhat.com> Jerome Glisse <jglisse@redhat.com> Signed-off-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-