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 08:09:24 -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 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.

OTOH, if you're just talking about mapping sections of VRAM to user level 
processes to manage as indpendent heads, that's fairly trivial to do as 
you say, but you'd almost certainly want acceleration for any sort of real 
world application, which is where things would get tricky.

> How are you reconciling the introduction of a new mode setting API
> with the 90 existing fbdev drivers? We clearly don't want two
> competing APIs in the kernel. What's the plan for converting all of
> the existing drivers?

My initial plan was to only convert drivers to this new API if they had 
hardware that justified a DRM driver (i.e. high performance devices with 
command ring buffers, 3D, etc.), and leave the other FB drivers alone, 
since the FB layer is quite suited to simple devices.

The other option of course is to port the existing drivers over to the new 
modesetting interfaces, though I suspect in many cases that may not be 
particularly useful.  I'm open to suggestions.

Thanks,
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/