linux-kernel - Re: [RFC] enhancing the kernel's graphics subsystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 21 May 2007 09:14:22 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	"Jon Smirl" <jonsmirl@...il.com>
Cc:	"Jon Smirl" <jonsmirl@...il.net>,
	"Jesse Barnes" <jesse.barnes@...el.com>,
	linux-kernel@...r.kernel.org,
	"Antonino A. Daplas" <adaplas@...il.com>
Subject: Re: [RFC] enhancing the kernel's graphics subsystem

On Monday, May 21, 2007, Jon Smirl wrote:
> On 5/21/07, Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
> > On Sunday, May 20, 2007, Jon Smirl wrote:
> > > On 5/20/07, Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
> > > > With the interfaces implemented here, a userspace application can
> > > > create a multiseat environment either with a single graphics card
> > > > with multiple outputs or multiple cards.  It could do this by
> > > > creating several frame buffer objects and associating them with
> > > > whatever CRTCs were available, and managing input via existing
> > > > APIs.  I don't know of anyone that's done this yet though...
> > >
> > > This design still requires a global server app since the heads share
> > > a single device.
> > > I am always concerned that the root priv code in the X server is a
> > > potential security hole. I would like to move away from a model
> > > where there is a global controlling app. I don't think we need a
> > > global controlling app at all.
> >
> > Even without a graphics server of some sort arbitrating access (and it
> > doesn't have to be a big as the current X server btw), you'd still
> > need your apps to take a card specific lock and/or coordinate so that
> > they don't clobber one another's rendering results.  This could be
> > done in the kernel, but for many devices the complexity added is
> > likely to be pretty high.
>
> We have already have the card specific locks, it's how Direct Rendering
> works.
>
> Besides, card locks are a much better design that the free for all
> that happens on a VT switch.

Right, I'm just saying there's much more to it than just having the 
hardware locks (which of course we already have).

> There is more to fbdev than mode setting. It is also how non-x86
> platforms achieve their boot display. How will boot display be handled
> with the your design? What about console display on non-x86 platforms?
> Loading both fbdev and the new code puts us right back into the
> multiple driver fight we have today.

Maybe you should take a look at the patches. :)  The code I posted actually 
creates an fb device as a slave of the DRM device, and uses that for the 
boot console.  Once you've booted, you can use the new interfaces to do 
whatever you want with the graphics device... though it doesn't 
create /dev/fb* devices per-CRTC like you seem to want, it's really easy 
to do the equivalent with a small userspace program (though I haven't 
actually tested sharing of buffer objects, it should work).

> If the kernel graphics system is going to get rewritten the rewrite
> needs to address all of the existing problems.

Sure, I have no problem with that, but there are usually lots of ways to 
solve a given problem.

Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/