-----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
