On 6/18/05, Adam Jackson <[EMAIL PROTECTED]> wrote: > On Saturday 18 June 2005 15:22, Jon Smirl wrote: > > On 6/18/05, Adam Jackson <[EMAIL PROTECTED]> wrote: > > > The point to notice here is that these registers generally segmented > > > apart in the card's memory map. If all those trigger regs are within a > > > single 4k range, then that's the only range you need to hide from > > > userspace. > > > > Then this is a card by card problem. If user space needs to get to the > > registers, and we can't split the safe registers from the unsafe > > (security issues) ones, then the user space drivers also needs to run > > as root. > > You sound really confused here. > > Obviously determining which sets of registers can be mapped through the drm is > a card-by-card problem. Different cards have different register maps, by > definition. But the DRI drivers work as a normal user _right_ _now_, and > (modulo mach64 and possibly r300) they seem to be secure.
There are more security holes than just restricting AddMap. If a normal user has register access to some cards (like the radeon), they can program the DMA controller to write into system RAM. You can use the ability to write into system RAM to gain root priv. I don't think we have good enough docs on any of the cards to says with 100% certainty that it is safe to allow a normal user access to the registers. It is still ok to create a permanent map for the registers these maps should just be marked _DRM_RESTRICTED to prevent non-root from mapping them. I'm still investigating things to see if it is possible to permanently create all of the maps needed. I know we can do it for registers and framebuffer. I just looked at sarea and that looks doable but I haven't written code to try it yet. I haven't gotten to the agp/pci maps yet. If all of the maps are permanently created AddMap can be turned into a noop. > > The issue is that drmAddMap, the function that sets up these maps, is > currently run from the server during DDX bringup. These maps can just as > easily be created during DRM init - and as a design issue, probably _should_ > be created there. And if we do that, nothing else in the server-side libdrm > API needs to be run as root (that I can see). I worte the initmap code in radeon that sets up the permanent maps for framebuffer and registers. > The client-side API doesn't need root anyway. But please don't add any calls > into the server-side API to the loadable driver. I know miniglx did it, but > that doesn't mean it's not a bad idea. The server-side API belongs > _exclusively_ in the server. I haven't seen a need to add any calls yet. > > > That's the whole point of the authmagic mechanism. The client gets a > > > magic number from the kernel via drmGetMagic, and passes that up to the > > > server in the XF86DRIAuthConnection call. The server checks that the > > > client is properly authenticated, and tells the DRM to allow that magic > > > number full authenticated (but not root-level) DRM access. > > > > The auth mechanism has an implicit root capability check in it. I want > > to remove the need for the server to be root to authorize other users > > so I need to remove that check. I also want to assign ownership of the > > dri/cardX device to the logged in user. > > And I'm saying that removing that check looks to be safe to do as long as > you're okay with racing to be the first DRI server. It makes sense that the first opener becomes the master. How else would you do it? > > If this check is removed then we have to make sure all of the driver > > IOCTLs are safe. Without this check I can just write a normal app that > > opens DRM and authenticates itself since the first opener of the DRI > > device becomes master. > > > > This is different than what you are talking about, I don't think you > > caught the part about removing the root check on the magic > > transaction. > > No, I got it. > > My point was that, excluding drmAddMap, the libdrm API that is currently > root-only can (AFAICT) be safely run as a user (ie, have the root check > removed) without reducing overall system security, as long as you restrict it > to the DRI server that currently owns the card. Or, more strongly, to the > first DRI server that registers itself, since we currently don't have any > logic for supporting multiple DRI servers. I know of at least three holes: 1) drmAddMap 2) normal user access to the registers. 3) normal user sending unverified commands - you have to make sure that a normal user can't send commands to the GPU that instruct it to do unrestricted writes to system memory by manipulating buffer pointers. I also want to feel comfortable that you can't pervert any of the other DRM ioctls into achieving one of these holes. -- Jon Smirl [EMAIL PROTECTED] ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
