--- Nicolai Haehnle <[EMAIL PROTECTED]> wrote:
> On Monday 01 November 2004 07:01, Thomas Hellström wrote:
> > You are probably right, and it would be quite easy to implement such
> > checks in the via command verifier as long as each lock is associated
> with
> > a certain hardware address range.
> >
> > However, I don't quite see the point in plugging such a security hole
> when
> > there are a similar ways to accomplish DOS, hardware crashes and even
> > complete lockups using DRI.
> >
> > On via, for example, writing random data to the framebuffer, writing
> > random data to the sarea, taking the hardware lock and sleeping for an
> > indefinite amount of time. Writing certain data sequences to the HQV
> locks
> > the north bridge etc.
> >
> > Seems like DRI allow authorized clients to do these things by design?
>
> From what I've learned, the DRI isn't exactly designed for robustness.
> Still, an authorized client should never be able to cause a hardware
> crash/lockup, and an authorized client must not be able to issue
> arbitrary
> DMA requests. As far as I know, all DRMs that are enabled by default
> enforce at least the latter.
>
> Personally I believe that in the long term, the DRI should have (at
> least)
> the following security properties:
> 1. Protect against arbitrary DMA (arbitrary DMA trivially allows
> circumvention of process boundaries)
> This can be done via command-stream checks.
>
> 2. Prevent hardware lockup or provide a robust recovery mechanism
> (protection of multi-user systems, as well as data protection)
> Should be relatively cheap via command-stream checks on most hardware
> (unless there are crazy hardware problems with command ordering like
> there
This is something I think has been discussed. Hopefully the DRM currently
varifies the cmd stream so that only the order in DRI's client side
drivers is accepted. Other ordering could be fixed, sine the size of the
cmds dosen't change, by simply memcpy'ing every thing into this right
order.
> seem to be on some Radeons). I believe that in the long term, recovery
> should be in the kernel rather than the X server.
>
> 3. Make sure that no client can cause another client to crash
> (malfunctioning clients shouldn't cause data loss in other applications)
> In other words, make sure that a DRI client can continue even if the
> shared
> memory areas are overwritten with entirely random values. That does seem
>
> like a daunting task.
>
> 4. Make sure that no client can block access to the hardware forever
> (don't
> force the user to reboot)
> I have posted a watchdog patch that protects against the "take lock,
> sleep
> forever" problem a long time ago. The patch has recently been updated by
>
> Dieter Nützel (search for updated drm.watchdog.3). However, I have to
> admit
> that the patch doesn't feel quite right to me.
>
> 5. Enable the user to kill/suspend resource hogs
> Even if we protect against lock abuse, a client could still use
> excessive
> amounts of texture memory (thus causing lots of swap) or emit rendering
> calls that take extremely long to execute. That kills latency and makes
> the
> system virtually unusable. Perhaps the process that authorizes DRI
> clients
> should be able to revoke or suspend that authorization. A suspend would
> essentially mean that drmGetLock waits until the suspend is lifted.
>
> I know that actually implementing these things in such a way that they
> Just
> Work is not a pleasant task. I just felt like sharing a brain dump.
>
> cu,
> Nicolai
>
> ATTACHMENT part 2 application/pgp-signature
__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
