OpenBSD Journal

Xenocara - Integrating X.org in OpenBSD

Contributed by deanna on from the it needs an icon dept.

Matthieu Herrb's presentation from FOSDEM 2007 has been added to the papers collection on openbsd.org. The presentation covers topics like the Xenocara build system, OpenBSD-specific security features of Xorg past, present and future, and the work that must be done to keep it all portable to systems other than i368/Linux.

(Comments are closed)

Comments

  1. By Anonymous Coward (195.159.118.253) on

    The X server having full control on the hardware via I/O ports and physical memory access breaks these models (see Loic Duflot’s paper at CanSecWest’06).

    Something ought to be done about that...

    Why isn't it possible to restrict X.org's memory access - i.e. only to those memory segments and IO ports allocated to the graphics hardware? Of course, X.org's horrendous PCI-scanning/probing will not work, but that's really no loss since most X.org drivers can be configured manually, IIRC.

    Comments

    1. By Anonymous Coward (151.136.100.2) on

      > The X server having full control on the hardware via I/O ports and
      > physical memory access breaks these models (see Loic Duflot’s
      > paper at CanSecWest’06).
      >
      > Something ought to be done about that...
      >
      > Why isn't it possible to restrict X.org's memory access - i.e. only to those memory segments and IO ports allocated to the graphics hardware?
      >
      > Of course, X.org's horrendous PCI-scanning/probing will not work, but that's really no loss since most X.org drivers can be configured manually, IIRC.

      get a clue -- read the papers.

    2. By Anonymous Coward (68.148.1.194) on

      > The X server having full control on the hardware via I/O ports and
      > physical memory access breaks these models (see Loic Duflot’s
      > paper at CanSecWest’06).
      >
      > Something ought to be done about that...
      >
      > Why isn't it possible to restrict X.org's memory access - i.e. only to those memory segments and IO ports allocated to the graphics hardware?
      >
      > Of course, X.org's horrendous PCI-scanning/probing will not work, but that's really no loss since most X.org drivers can be configured manually, IIRC.

      What's the difference? If I can convince the DMA engine or sprite
      engine on a graphics card to overwrite any portion of memory? I mean,
      I draw an exploit pattern onto a portion of the screen, and then get
      the card itself to store it back to a portion of kernel memory...

    3. By David Chisnall (137.44.2.39) on

      > Why isn't it possible to restrict X.org's memory access - i.e. only to those memory segments and IO ports allocated to the graphics hardware?

      Most graphics hardware is capable of DMA transfers these days. This means that the hardware can write directly to (or read from) any part of physical memory. If you restrict the driver's address space using the CPU's MMU (as you do for all processes), then this doesn't prevent it from instructing the device to DMA data to or from anywhere else. Sometimes, you even want this (for example having the device read a texture or pixmap from a program's address space).

      More modern machines (latest x86-64 systems, and a lot of SPARCs) come with an IOMMU[1], which does the same thing for hardware that the CPU's MMU does for processes. If the drivers were written to be aware of this (which might require a modification of the X.org driver model; I'm not intimately familiar with X.org), then the kernel could control the IOMMU and open up just the required windows on behalf of the driver.


      [1] AGP specifies an IOMMU in the form of the GART, but I believe this is quite primitive. It is mainly used to allow the kernel to allocate a block of main memory to use as graphics RAM.

  3. By Kernigh (69.138.228.251) on http://kernigh.pbwiki.com/OpenBSD

    I put GNU/Linux on a macppc machine in 2001. In 2003, there were no good Linux distros for macppc. That year I tried OpenDarwin and NetBSD but could not make XFree86 work. So I switched to OpenBSD 3.3 because "startx" works without configuration (and also because OpenBSD builds KDE every six months). The default XF86Config used wsfb, which in turn used vgafb(4), the unaccelerated 8bpp Open Firmware framebuffer (as explained in /usr/X11R6/README). That satisfied me until I could hack an XF86Config from Linux to give me 16bpp in OpenBSD.

    Now I have a newer macppc machine, a PowerBook5,4 which dual boots Mac OS X, but mostly runs OpenBSD. It was Xorg 6.8.2 (OpenBSD 3.7) replacing XFree86 4.4-lite (OpenBSD 3.6) that fixed a bug in accelerated X. Now I can have accelerated X (but no Xrender 2D acceleration) just by doing...

    mv /etc/X11/xorg.conf /somewhere/else
    startx

    ...and Xorg configures itself for 16bpp graphics. Using the xrandr command I can comfortably change the screen resolution, that once-impossible task.

    OpenBSD does not have DRI, so I cannot do accelerated 3D. Linux/macppc users (who often switch distros) tell me that DRI with the ATI cards in Macintoshes usually crashes the operating system. The real problem here is ATI not providing documentation.

    It is nice to know that OpenBSD still cares about multiplatform X.

  4. By Anonymous Coward (71.146.186.179) on

    typo: OpenBPd -> OpenBGPd

    (next time please include some contact info? :)

    Comments

    1. By Deanna Phillips (deanna) on

      > (next time please include some contact info? :)

      Oops. The paper was written by matthieu@, the OpenBSD X maintainer and an Xorg developer. (That's matthieu at openbsd org).

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]