1. 09 2月, 2010 4 次提交
  2. 05 2月, 2010 2 次提交
  3. 01 2月, 2010 1 次提交
  4. 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
  5. 14 1月, 2010 1 次提交
  6. 08 1月, 2010 3 次提交
  7. 23 12月, 2009 1 次提交
  8. 16 12月, 2009 2 次提交
  9. 10 12月, 2009 2 次提交
  10. 08 12月, 2009 4 次提交
  11. 04 12月, 2009 1 次提交
  12. 02 12月, 2009 6 次提交
  13. 24 11月, 2009 1 次提交
    • D
      drm/radeon/kms: resume AGP by calling init. · 0ebf1717
      Dave Airlie 提交于
      AGP resume was broken since we moved to the new init path,
      because we never re-enabled AGP on these systems at resume time.
      
      This patch just calls the AGP resume call which just does the reinit
      at resume time like the old path did.
      
      Since AGP is pretty much gpu independant I did it outside
      the gpu specific code.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      0ebf1717
  14. 06 11月, 2009 1 次提交
  15. 26 10月, 2009 1 次提交
  16. 16 10月, 2009 1 次提交
  17. 02 10月, 2009 6 次提交