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 for Android: free password hash cracker in your pocket

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

Message-ID: <9e4733910705201747n1847f7b1wd57a8e8640a857a8@mail.gmail.com>
Date:	Sun, 20 May 2007 20:47:56 -0400
From:	"Jon Smirl" <jonsmirl@...il.com>
To:	"Jesse Barnes" <jbarnes@...tuousgeek.org>
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 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.

By making one device per head it becomes possible to assign ownership
of the device to the specific user and let them do whatever they want
to it. It's then up to the device driver to sort everything out. fbdev
has already been designed with this in mind and I believe the Matrox
driver implements it. This model easily expands from one to N heads.

Merged-fb modes are handled by including them in the allowable modes
list on both heads. If you own both heads you can set a merged-fb mode
and the other device will just return EBUSY.

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?

-- 
Jon Smirl
jonsmirl@...il.com
-
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/