Menu
▾
▴
linux-fbdev-devel
|
From: Matt S. <mat...@ho...> - 2001-11-22 07:22:33
|
>> Currently mmio and fb pointers are in a PUBLIC data structure, a data >> structure that is defined for everyone using the fb interfaces, both >> kernel side and user side. >That is so you can do things like use the physical memory address of >the framebuffer to display a image from a TV card into it. No doubt, as you state, there are applications that would need the physical framebuffer address. The problem is that when you just leave a pointer laying around in a public data structure there is no way for a user application to know when the pointer is valid and when it is not. If a unsuspecting TV capture card tried to use my physical address without knowing that I only have 64k banks the whole system would come down hard. I could see a physical pointer in a mode based data structure (similar to "var") with the knowledge that it can be 0 if the fb is not directly accessible. Also such a data structure would be where you could find an "offset" and "size" to use as mmap parameters. "size" being 0 if mmap isn't possible. >The framebuffer itself is pretty safe to export to userland. I assume you mean to allow people to mmap the framebuffer? Yes this can usually be safe, but only the screen data. Most chips use graphics memory of some type for dma command buffers. Most chips cannot safely give you full access to such memory areas. The sysmem_start and sysmem_length seem to cover the whole graphics region, not just the visible framebuffer. This is likely not safe. MMap is essential for lots of applications. I'm all in favor of allowing it where possible. This isn't the kind of direct access I was against. Mmap IS a driver interface. I can do all kind of tricks in the driver to make sure a user who mmaps the framebuffer only gets access to what they are supposed to. In my stolen memory driver I have zero-page fault handlers to map and unmap regions while changing memory banks on the fly. I can't do this when the kernel dereferences a kernel-virtual address as is done in the logo code. There is no page fault handler for me to catch. >MMIO can be tricker. The area of graphics resource management is really >complex. For now I'm just aiming to get a clean seperation of the >console system out of the framebuffer layer. MMio is a very different animal. Most mmio regions are not safe for untrusted userspace binaries to access. This is why such access is limited to root. Further there is no generic use for these mmio regions, only a userspace driver would know what to do with them. Certainly a userspace driver and kernelspace driver that are working together should be able to work out a way to share the locations they need without leaving them lay around in public. >Personally I like to see the day when DRI and the fbdev layer are >merged but that will be awhile. Yes me too, but a lot of cleanup needs to be done in fb land before anyone should consider it. The drm code is pretty well designed and doesn't have the kind of cruft that has built up on the fb interfaces. I would really like to get as many people looking at the whole fb interface with a very critical eye. 2.5.x is the best opportunity we will have to make drastic changes. We will have a very long time before 3.0.0(?) to get things in shape. I don't want to settle for half-done redesign when we could really make a good solid base to build on for the next several years. -Matt |
|
From: Sven <lu...@dp...> - 2001-11-22 08:38:52
|
On Thu, Nov 22, 2001 at 12:34:03AM -0800, Matt Sottek wrote: > >The framebuffer itself is pretty safe to export to userland. > > I assume you mean to allow people to mmap the framebuffer? Yes this can > usually be safe, but only the screen data. Most chips use graphics > memory of some type for dma command buffers. Most chips cannot safely > give you full access to such memory areas. The sysmem_start and > sysmem_length seem to cover the whole graphics region, not just the > visible framebuffer. This is likely not safe. DMA is not useable outside of the DRI anyway for now, or do you know of any userland app doing this ? I guess you need to have root access to the fbdev or something such to be able to do dma, not sure though. Anyway, even X is not able to do DMA outside of the DRI setup. I would have liked it when writing Xv support for the permedia3 chip. Friendly, Sven Luther |
|
From: Matt S. <mat...@ho...> - 2001-11-22 09:28:28
|
On Thu, 2001-11-22 at 00:37, Sven wrote: > On Thu, Nov 22, 2001 at 12:34:03AM -0800, Matt Sottek wrote: > > >The framebuffer itself is pretty safe to export to userland. > > > > I assume you mean to allow people to mmap the framebuffer? Yes this can > > usually be safe, but only the screen data. Most chips use graphics > > memory of some type for dma command buffers. Most chips cannot safely > > give you full access to such memory areas. The sysmem_start and > > sysmem_length seem to cover the whole graphics region, not just the > > visible framebuffer. This is likely not safe. > > DMA is not useable outside of the DRI anyway for now, or do you know of any > userland app doing this ? > > I guess you need to have root access to the fbdev or something such to be able > to do dma, not sure though. Yes only the DRI is doing dma. It doesn't matter who is doing it. What I was pointing out is that you cannot just let users map the "framebuffer" memory (meaning all of the graphics memory) because some of that memory may contain active dma command buffers which could be hijacked to do insecure things. Like, for instance, blit something from system memory into the framebuffer such that you can then read it, or write to random areas of memory. > > Anyway, even X is not able to do DMA outside of the DRI setup. I would have > liked it when writing Xv support for the permedia3 chip. > So write a DRM :) -Matt |
|
From: Sven <lu...@dp...> - 2001-11-22 10:27:38
|
On Thu, Nov 22, 2001 at 02:40:00AM -0800, Matt Sottek wrote: > On Thu, 2001-11-22 at 00:37, Sven wrote: > > On Thu, Nov 22, 2001 at 12:34:03AM -0800, Matt Sottek wrote: > > > >The framebuffer itself is pretty safe to export to userland. > > > > > > I assume you mean to allow people to mmap the framebuffer? Yes this can > > > usually be safe, but only the screen data. Most chips use graphics > > > memory of some type for dma command buffers. Most chips cannot safely > > > give you full access to such memory areas. The sysmem_start and > > > sysmem_length seem to cover the whole graphics region, not just the > > > visible framebuffer. This is likely not safe. > > > > DMA is not useable outside of the DRI anyway for now, or do you know of any > > userland app doing this ? > > > > I guess you need to have root access to the fbdev or something such to be able > > to do dma, not sure though. > > Yes only the DRI is doing dma. It doesn't matter who is doing it. > > What I was pointing out is that you cannot just let users map the > "framebuffer" memory (meaning all of the graphics memory) because some > of that memory may contain active dma command buffers which could be > hijacked to do insecure things. Like, for instance, blit > something from system memory into the framebuffer such that you > can then read it, or write to random areas of memory. And you can open the fbdev once X has locked it and do mma stuff ? > > Anyway, even X is not able to do DMA outside of the DRI setup. I would have > > liked it when writing Xv support for the permedia3 chip. > > > So write a DRM :) mmm, ... I was in the process of doing this, mainly for DRI and OpenGL purpose, it partly exists already anyway, but then RL asserted itself again, and i don't have the time anymore :(((( Maybe later on ... Friendly, Sven Luther > > -Matt > > |
|
From: Michel <mic...@ii...> - 2001-11-22 09:32:41
|
On Thu, 2001-11-22 at 09:37, Sven wrote: > Anyway, even X is not able to do DMA outside of the DRI setup. I would ha= ve > liked it when writing Xv support for the permedia3 chip. DMA sure isn't possible without kernel support, but you only need a DRM, see a recent version of r128_video.c. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: James S. <jsi...@tr...> - 2001-11-24 17:24:50
|
> DMA is not useable outside of the DRI anyway for now, or do you know of any > userland app doing this ? Nope. Do to the lack of docs on programming the api you haven't seen anything done. > I guess you need to have root access to the fbdev or something such to be able > to do dma, not sure though. No root!!! If the RRM is design right you don't need root. Well except for the master node (SGI terminology) that controls the global state. For example root would only change the resolution since this can affect every client using the accel engine. Even that I think doesn't have to be root. > Anyway, even X is not able to do DMA outside of the DRI setup. I would have > liked it when writing Xv support for the permedia3 chip. That sucks :-( |
|
From: Geert U. <ge...@li...> - 2001-11-22 10:04:07
|
On 22 Nov 2001, Matt Sottek wrote:
> >> Currently mmio and fb pointers are in a PUBLIC data structure, a data
> >> structure that is defined for everyone using the fb interfaces, both
> >> kernel side and user side.
>
> >That is so you can do things like use the physical memory address of
> >the framebuffer to display a image from a TV card into it.
>
> No doubt, as you state, there are applications that would need the
> physical framebuffer address. The problem is that when you just leave
> a pointer laying around in a public data structure there is no way
> for a user application to know when the pointer is valid and when it
> is not. If a unsuspecting TV capture card tried to use my physical
> address without knowing that I only have 64k banks the whole system
> would come down hard.
If it's not safe to use the pointer, set it to NULL and set the size to 0 as
well.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Sven <lu...@dp...> - 2001-11-22 10:25:42
|
On Thu, Nov 22, 2001 at 10:32:28AM +0100, Michel D=E4nzer wrote: > On Thu, 2001-11-22 at 09:37, Sven wrote: >=20 > > Anyway, even X is not able to do DMA outside of the DRI setup. I woul= d have > > liked it when writing Xv support for the permedia3 chip. >=20 > DMA sure isn't possible without kernel support, but you only need a DRM= , > see a recent version of r128_video.c. Well, and the DRM takes care of security issues, isn't it ? That said, i don't really have time for playing with X right now, but i a= m aware of the use of DRM for r128. It is linux specific though. the point was for people misusing the mmio pointer provided by fbdev. Friendly, Sven Luther |
|
From: Michel <mic...@ii...> - 2001-11-22 10:53:57
|
On Thu, 2001-11-22 at 11:23, Sven wrote: > On Thu, Nov 22, 2001 at 10:32:28AM +0100, Michel D=E4nzer wrote: > > On Thu, 2001-11-22 at 09:37, Sven wrote: > >=20 > > > Anyway, even X is not able to do DMA outside of the DRI setup. I woul= d have > > > liked it when writing Xv support for the permedia3 chip. > >=20 > > DMA sure isn't possible without kernel support, but you only need a DRM= , > > see a recent version of r128_video.c. >=20 > Well, and the DRM takes care of security issues, isn't it ? Yes. > That said, i don't really have time for playing with X right now, but i a= m > aware of the use of DRM for r128. It is linux specific though. No, it should work on BSD now and on all platforms once the DRM is ported. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: James S. <jsi...@tr...> - 2001-11-24 17:21:14
|
> >> Currently mmio and fb pointers are in a PUBLIC data structure, a data > >> structure that is defined for everyone using the fb interfaces, both > >> kernel side and user side. > > >That is so you can do things like use the physical memory address of > >the framebuffer to display a image from a TV card into it. > > No doubt, as you state, there are applications that would need the > physical framebuffer address. The problem is that when you just leave > a pointer laying around in a public data structure there is no way > for a user application to know when the pointer is valid and when it > is not. If a unsuspecting TV capture card tried to use my physical > address without knowing that I only have 64k banks the whole system > would come down hard. Ah. You are talking about having a real RRM (rendering resource manager). When a process open /dev/fb or DRI it should be registered with the RRM. Then when someone does something global like change the graphics resolution the RRM sends a signal to all the processes that are using the graphics card resources. As for the 64k bank sitution you can use VM tricks to make it appeard linear to userland. If you something really bizarre then you add something on the order of: #define FB_AUX_TEXT_MDA 0 /* Monochrome text */ #define FB_AUX_TEXT_CGA 1 /* CGA/EGA/VGA Color text */ #define FB_AUX_TEXT_S3_MMIO 2 /* S3 MMIO fasttext */ #define FB_AUX_TEXT_MGA_STEP16 3 /* MGA Millenium I: text, attr, 14 This tells userland youhave something weird so watch out. > memory of some type for dma command buffers. Most chips cannot safely > give you full access to such memory areas. The sysmem_start and > sysmem_length seem to cover the whole graphics region, not just the > visible framebuffer. This is likely not safe. Then the driver is broken. This wouldn't be a first :-( > Mmap IS a driver interface. I can do all kind of tricks in the driver to > make sure a user who mmaps the framebuffer only gets access to what they > are supposed to. In my stolen memory driver I have zero-page fault > handlers to map and unmap regions while changing memory banks on the > fly. Nice tricks. > I can't do this when the kernel dereferences a kernel-virtual > address as is done in the logo code. There is no page fault handler for > me to catch. Don't worry this will go away in 2.5.X. The virtual poniter will remain for cards that need it, lacking any kind of acceleration. Since most cards are acclerated, even most embedded chips, the virtual pointer becomes optional. That is the key point. It is optional. That pointer then is only accessed in the software emulated accel functions that are needed. > MMio is a very different animal. Most mmio regions are not safe for > untrusted userspace binaries to access. This is why such access is > limited to root. Further there is no generic use for these mmio regions, > only a userspace driver would know what to do with them. Certainly a > userspace driver and kernelspace driver that are working together should > be able to work out a way to share the locations they need without > leaving them lay around in public. It doesn't have to be root. DRI allows normal clients to use the MMIO regions. The key is that you have a RRM that is the guardian angel. If a process does the naughty you kill it and reset the accel engine. > I would really like to get as many people looking at the whole fb > interface with a very critical eye. 2.5.x is the best opportunity we > will have to make drastic changes. We will have a very long time > before 3.0.0(?) to get things in shape. I don't want to settle for > half-done redesign when we could really make a good solid base to > build on for the next several years. I have been working on the fbdev api since janurary 1999. Part of it went in but unfortunely the TTY/console system lacked the power to allow the rest in. Now I have rewritten the console system to handle it. In the process I have realized how I could write wrapper until the TTY/console system gets cleaned up by me. |
|
From: Matt S. <mat...@ho...> - 2001-11-25 01:04:02
|
> > No doubt, as you state, there are applications that would need the > > physical framebuffer address. The problem is that when you just leave > > a pointer laying around in a public data structure there is no way > > for a user application to know when the pointer is valid and when it > > is not. If a unsuspecting TV capture card tried to use my physical > > address without knowing that I only have 64k banks the whole system > > would come down hard. > > Ah. You are talking about having a real RRM (rendering resource manager). > When a process open /dev/fb or DRI it should be registered with the RRM. > Then when someone does something global like change the graphics > resolution the RRM sends a signal to all the processes that are using the > graphics card resources. As for the 64k bank sitution you can use VM > tricks to make it appeard linear to userland. If you something really > bizarre then you add something on the order of: > No I wasn't talking about anything that complex. I just don't want userland or anyone outside my driver using the pointers I am required to provide. I'm just going to set them all to zero, and whatever falls over needs to be fixed. > > MMio is a very different animal. Most mmio regions are not safe for > > untrusted userspace binaries to access. This is why such access is > > limited to root. Further there is no generic use for these mmio regions, > > only a userspace driver would know what to do with them. Certainly a > > userspace driver and kernelspace driver that are working together should > > be able to work out a way to share the locations they need without > > leaving them lay around in public. > > It doesn't have to be root. DRI allows normal clients to use the MMIO > regions. The key is that you have a RRM that is the guardian angel. If a > process does the naughty you kill it and reset the accel engine. > No it doesn't. The DRM only allows clients to map regions that are safe. This doesn't include the mmio registers for most cards. The drm provides safe interfaces to do dma and dispatch commands. It doesn't just let clients touch the registers. For instance on i810 you can map a dma buffer into the client but in order to dispatch a command the kernel unmaps the buffer from the client writes the instruction to the dma buffer and then dispatched the buffer. It isn't safe on i810 to allow the client full access even to the dma buffers. It isn't like the kernel gives you full access but will kill you if you do something wrong, there is no interface to allow you to do something wrong in the first place. I think the kgi does more of what you are talking about here. -Matt |
|
From: James S. <jsi...@tr...> - 2001-11-25 05:51:21
|
> No I wasn't talking about anything that complex. I just don't want > userland or anyone outside my driver using the pointers I am required > to provide. I'm just going to set them all to zero, and whatever falls > over needs to be fixed. Set the fb_fix fields for mmio and smem to zero. As for internally with the new api you don't need to use the screen_base field. Just ignore it. > It isn't like the > kernel gives you full access but will kill you if you do something > wrong, there is no interface to allow you to do something wrong in > the first place. > > I think the kgi does more of what you are talking about here. No KGI works just the way you described DRI does. KGI uses a metadata system to render graphics commands. Basically you can create data packets of what you want done and send it out. The kernel interpets the data and executes it safely. Well okay KGI takes it a step further than DRI. The method I described is the way IRIX handles it on SGI systems. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X