Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 18 2月, 2010 1 次提交
  3. 16 2月, 2010 1 次提交
    • J
      drm/radeon/kms: fix indirect buffer management V2 · e821767b
      由 Jerome Glisse 提交于 
      There is 3 different distinct states for an indirect buffer (IB) :
  1- free with no fence
  2- free with a fence
  3- non free (fence doesn't matter)
Previous code mixed case 2 & 3 in a single one leading to possible
catastrophique failure. This patch rework the handling and properly
separate each case. So when you get ib we set the ib as non free and
fence status doesn't matter. Fence become active (ie has a meaning
for the ib code) once the ib is scheduled or free. This patch also
get rid of the alloc bitmap as it was overkill, we know go through
IB pool list like in a ring buffer as the oldest IB is the first
one the will be free.

Fix :
https://bugs.freedesktop.org/show_bug.cgi?id=26438
and likely other bugs.

V2 remove the scheduled list, it's useless now, fix free ib scanning
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      e821767b
  5. 11 2月, 2010 2 次提交
    • D
      drm/radeon/kms: set gart pages to invalid on unbind and point to dummy page · 82568565
      由 Dave Airlie 提交于 
      this uses a new entrypoint to invalidate gart entries instead of using 0.
Changed to rather than pointing to 0 address point empty entry to dummy
page. This might help to avoid hard lockup if for some wrong
reasons GPU try to access unmapped GART entry.

I'm not 100% sure this is going to work, we probably need to allocate
a dummy page and point all the GTT entries at it similiar to what AGP does.
but we can test this first I suppose.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      82568565
    • J
      drm/radeon/kms: r600/r700 command stream checker · 961fb597
      由 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>
      961fb597
  7. 09 2月, 2010 11 次提交
  9. 05 2月, 2010 2 次提交
  11. 01 2月, 2010 1 次提交
  13. 21 1月, 2010 3 次提交
    • J
      drm/radeon: r6xx/r7xx possible security issue, system ram access · c8c15ff1
      由 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>
      c8c15ff1
    • J
      drm/radeon/kms: r600/r700 disable irq at suspend · 0c45249f
      由 Jerome Glisse 提交于 
      To avoid hw doing anythings after we disabled PCIE GART, fully
disable IRQ at suspend. Also cleanup a bit the ih structure
and process function.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>
      0c45249f
    • A
      drm/radeon/kms: fix hardcoded mmio size in register functions · 07bec2df
      由 Alex Deucher 提交于 
      newer asics have large mmio apertures
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>
      07bec2df
  15. 14 1月, 2010 1 次提交
  17. 08 1月, 2010 3 次提交
  19. 23 12月, 2009 1 次提交
  21. 16 12月, 2009 2 次提交
  23. 10 12月, 2009 2 次提交
  25. 08 12月, 2009 4 次提交
  27. 04 12月, 2009 1 次提交
  29. 02 12月, 2009 5 次提交