Re: Removing the root priv requirement from DRM
Ian Romanick wrote: The problem with the SAREA is that user-mode can request an SAREA *larger* than the kernel knows about. For example, the user-mode drivers can add extra fields for the DDX and client-side drivers to communicate. The kernel doesn't need to know anything about what's in that memory. It just knows that user mode wants N bytes of shared space. If region is created in advance, there is no opportunity for user-mode to specify a size. HOWEVER, the map creation can still be done within the kernel during a bootstrap process. It would have been very easy for the MGA_DRM_BOOTSTRAP_DMA ioctl to create the mapping for the SAREA. The current model actually allows for the server to create a number of shared memory areas and to specify a flag for the one that contains the hardware lock. If this model is kept then the size of the sarea created at kernel module initialization time could IMHO be known by the kernel. If dri is used for other applications with special needs that does not fit in the defalult size (for example the unichrome XvMC in the future) they could create an sarea mapping of their own and should not need to be root to do this, perhaps master though, since the map handle still needs to be communicated to all clients. This would require the drmAddMap or similar functionality to remain. >Some drivers (e.g., pre-3.2 MGA DRM) poll registers to know when the >engine is idle. The radeon / r200 drivers can also fallback to >something similar if interrupts are not available. I think some of the >other drivers may do similar things. Unichrome is doing this as well. Both OpenGL and XvMC drivers. /Thomas If all of the maps are permanently created AddMap can be turned into a noop. s/If all of the maps are permanently created/When all map creation is moved into the kernel/ ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCtv0vX1gOwKyEAw8RAiE/AKCNiuRCyeW/G/7qkiNrSLPnKnoiZgCdHWQb EKvDG2Ojcy+L/cos60EnQiU= =BXDR -END PGP SIGNATURE- --- 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_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- 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_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
On 6/20/05, Ian Romanick <[EMAIL PROTECTED]> wrote: > The problem with the SAREA is that user-mode can request an SAREA > *larger* than the kernel knows about. For example, the user-mode > drivers can add extra fields for the DDX and client-side drivers to > communicate. The kernel doesn't need to know anything about what's in > that memory. It just knows that user mode wants N bytes of shared > space. If region is created in advance, there is no opportunity for > user-mode to specify a size. The size is still constained by SAREA_MAX right? If so the DRM driver can always allocate an SAREA of that size. -- 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
Re: Removing the root priv requirement from DRM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan Cox wrote: > On Sad, 2005-06-18 at 23:30, Adam Jackson wrote: > >>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). > > In some cases the maps cannot come into existance until the X server has > done the neccessary configuration to make the mapping of registers safe. > Similarly there are dependancies at points like mode change that require > care with what is exposed and active in order to avoid lockups. > Currently the X server handles this and whoever handles this needs to be > priviledged as they are able to get it wrong. Do you have any specific examples of drivers that work like that? That seems really odd, and I'd like to understand that code better. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCtxQEX1gOwKyEAw8RAi8WAKCHEZItwitzRELWFQd689jsf/jf/QCfY2zJ B+ID7xvGIPSvKzKaYlMl6OM= =GQ7C -END PGP SIGNATURE- --- 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_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
On Sad, 2005-06-18 at 20:22, Jon Smirl wrote: > 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. Incorrect. See the via driver. The maps are just a useful performance trick for some cards. --- 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_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
On Sad, 2005-06-18 at 23:30, Adam Jackson wrote: > 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). In some cases the maps cannot come into existance until the X server has done the neccessary configuration to make the mapping of registers safe. Similarly there are dependancies at points like mode change that require care with what is exposed and active in order to avoid lockups. Currently the X server handles this and whoever handles this needs to be priviledged as they are able to get it wrong. Alan --- 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_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nicolai Haehnle wrote: > I don't see any reason for mapping registers into userspace in the first > place. Except for mode setting and related setup tasks (which aren't > exactly performance critical), you'll never want to write to registers > directly but go through a DMA'd command stream. > > Okay, there may be ancient hardware that doesn't support that mode of > operation. But why not get rid of register maps completely for everything > else? Some drivers (e.g., pre-3.2 MGA DRM) poll registers to know when the engine is idle. The radeon / r200 drivers can also fallback to something similar if interrupts are not available. I think some of the other drivers may do similar things. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCtv2zX1gOwKyEAw8RApvqAJ9WKrppm2UgPLJXap9BXIZ6WeS4JgCgkLgw 25gQUiS+sUmxjl/DHPvdwjI= =5IVT -END PGP SIGNATURE- --- 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_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Smirl wrote: > 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. Right now the 3.2 MGA DRM does the AddMap for MMIO registers in the kernel. The map is added as DRM_READONLY (and never returned to user-mode, but that's another story). There are three things to take home here: 1. User-mode does not /need/ to AddMap *anything* *ever*. 2. The kernel can make the same access decisions for MMIO space that the X-server makes. If all or part of MMIO space needs to be read-only, fine. If all or part of MMIO space can be read-write, fine. The kernel is a big boy and can do all that magic too. 3. In the auth/master/root view of things, the mapping is done (indirectly) by the master, and the master has no opportunity to create a security hole (e.g., by creating the map with open permissions instead of read-only). Also notice that there is no need for a permanent mapping of MMIO space. The mapping is created when the master bootstraps the card for DMA. > 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. The problem with the SAREA is that user-mode can request an SAREA *larger* than the kernel knows about. For example, the user-mode drivers can add extra fields for the DDX and client-side drivers to communicate. The kernel doesn't need to know anything about what's in that memory. It just knows that user mode wants N bytes of shared space. If region is created in advance, there is no opportunity for user-mode to specify a size. HOWEVER, the map creation can still be done within the kernel during a bootstrap process. It would have been very easy for the MGA_DRM_BOOTSTRAP_DMA ioctl to create the mapping for the SAREA. > If all of the maps are permanently created AddMap can be turned into a noop. s/If all of the maps are permanently created/When all map creation is moved into the kernel/ ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCtv0vX1gOwKyEAw8RAiE/AKCNiuRCyeW/G/7qkiNrSLPnKnoiZgCdHWQb EKvDG2Ojcy+L/cos60EnQiU= =BXDR -END PGP SIGNATURE- --- 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_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
On Monday 20 June 2005 00:03, Jon Smirl wrote: > On 6/18/05, Adam Jackson <[EMAIL PROTECTED]> wrote: > > 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. You still sound really confused here. You say there are more holes than just AddMap, but then go on to describe the hole in AddMap. The DMA controller doesn't just magically show up in a process' address space. It has to have been set up first, either through drmAddMap from a process running as root (and subsequent authorization and drmMap sequence), or from DRM setup (and auth and drmMap). - ajax pgp7pQ1Q9v8ic.pgp Description: PGP signature
Re: Removing the root priv requirement from DRM
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, straightf
Re: Removing the root priv requirement from DRM
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. 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). 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. > > 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. > 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. - ajax pgpKZMy0ai1W4.pgp Description: PGP signature
Re: Removing the root priv requirement from DRM
On Saturday 18 June 2005 21:03, Adam Jackson wrote: > On Saturday 18 June 2005 11:20, Jon Smirl wrote: > > Access to the registers is something that should require root priv > > right? Once I can get to the registers I can program them to contol > > the DMA hardware and then muck with the kernel's memory and escalate > > my priveldge level. EGL avoids this possible hole by not using the > > registers from user space. > > Not all register access should require root. In fact you want to do as much > as possible directly from userspace because shuffling large amounts of data > into the kernel is painful. So what you need to restrict are those registers > which can trigger reads and writes from arbitrary system memory bypassing the > MMU, which basically means anything that can trigger bus-master writes or > DMA. > > 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. I don't see any reason for mapping registers into userspace in the first place. Except for mode setting and related setup tasks (which aren't exactly performance critical), you'll never want to write to registers directly but go through a DMA'd command stream. Okay, there may be ancient hardware that doesn't support that mode of operation. But why not get rid of register maps completely for everything else? cu, Nicolai pgphGMxZv7NKH.pgp Description: PGP signature
Re: Removing the root priv requirement from DRM
On 6/18/05, Adam Jackson <[EMAIL PROTECTED]> wrote: > On Saturday 18 June 2005 11:20, Jon Smirl wrote: > > Access to the registers is something that should require root priv > > right? Once I can get to the registers I can program them to contol > > the DMA hardware and then muck with the kernel's memory and escalate > > my priveldge level. EGL avoids this possible hole by not using the > > registers from user space. > > Not all register access should require root. In fact you want to do as much > as possible directly from userspace because shuffling large amounts of data > into the kernel is painful. So what you need to restrict are those registers > which can trigger reads and writes from arbitrary system memory bypassing the > MMU, which basically means anything that can trigger bus-master writes or > DMA. > > 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. > EGL really has nothing to do with this, it's entirely a driver issue. I meant my radeon EGL driver. I am modifying it to run without root priv. > > My solution would be to leave the permament maps visible and then add > > a root capability check when someone attempts to drmMap the registers. > > It would more complex to try and hide the map from GetMap. > > 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. 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. -- 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
Re: Removing the root priv requirement from DRM
On Saturday 18 June 2005 11:20, Jon Smirl wrote: > Access to the registers is something that should require root priv > right? Once I can get to the registers I can program them to contol > the DMA hardware and then muck with the kernel's memory and escalate > my priveldge level. EGL avoids this possible hole by not using the > registers from user space. Not all register access should require root. In fact you want to do as much as possible directly from userspace because shuffling large amounts of data into the kernel is painful. So what you need to restrict are those registers which can trigger reads and writes from arbitrary system memory bypassing the MMU, which basically means anything that can trigger bus-master writes or DMA. 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. EGL really has nothing to do with this, it's entirely a driver issue. > My solution would be to leave the permament maps visible and then add > a root capability check when someone attempts to drmMap the registers. > It would more complex to try and hide the map from GetMap. 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 drm API really has three parts: base, authenticated, and master. drmMap is part of the authenticated API, so there's no need to add any additional hiding. Any sensitive register ranges would just be unavailable through drmMap and accessible only from the kernel side, and the safe ranges would only be available after a GetMagic/AuthConnection cycle. > I haven't gotten to where I need to AddMap sarea. Can we prebuild a > permanent map for it too? You could; I'm not sure you want to. In principle it should get charged to the DRM master process. But it's like two pages, not a huge deal either way. > Right now I'm blocked on the AuthMagic call needing root. Of the master-level API, I think only drmAddMap really needs to be restricted to root (to the extent it should exist at all). The rest can be made available to only the first DRM client to start (the server, presumably). I'm not entirely comfortable with that, but I can't completely articulate why yet... - ajax pgpuTXxvkbd7N.pgp Description: PGP signature
Removing the root priv requirement from DRM
I moved this to a new thread. I'd also like to ask everyone to help with this. I don't want to accidentally introduce a security hole; the more eyes looking at the code the less likely that will be. On 6/17/05, Adam Jackson <[EMAIL PROTECTED]> wrote: > drmAddMap has to be root-only because it's mapping device memory into > userspace (can trigger bus-master writes, blah blah, root escalation). I > think that's the only one that _really_ needs it, and to be honest those > mappings should get set up from the DRM side anyway and AddMap should just > die. I put code into radeon CVS for something I was calling permanent maps. When the driver loads it uses an internal call, initmap() to preload the maps for framebuffer and the registers. That allows you to avoid the AddMap calls for those two. I believe the via driver has picked up initmap too. Dave says initmap is already in the queue for kernel and should be landing shortly. Access to the registers is something that should require root priv right? Once I can get to the registers I can program them to contol the DMA hardware and then muck with the kernel's memory and escalate my priveldge level. EGL avoids this possible hole by not using the registers from user space. My solution would be to leave the permament maps visible and then add a root capability check when someone attempts to drmMap the registers. It would more complex to try and hide the map from GetMap. I haven't gotten to where I need to AddMap sarea. Can we prebuild a permanent map for it too? Right now I'm blocked on the AuthMagic call needing root. -- 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
