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 11:34:03 -0400
From:	"Jon Smirl" <jonsmirl@...il.com>
To:	"Jeff Garzik" <jeff@...zik.org>
Cc:	"Jesse Barnes" <jbarnes@...tuousgeek.org>,
	"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, Jeff Garzik <jeff@...zik.org> wrote:
> Jon Smirl wrote:
> > 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.
>
>
> If you have multiple "controlling" apps competing for a single device,
> that either implies complexity in each app for sharing control, or
> moving even more code into the kernel for 2D and 3D.
>
> I don't think the kernel community is yet interested in moving
> everything of consequence into the kernel.

Before dismissing this you might want to spend some time designing it.

When I said head I should have been more specific and said CRTC. CRTCs
are pretty much independent from each other and can be assigned one
per device. I believe this has already been done in the Matrox fbdev
driver. I have also prototyped this on the Radeon hardware and it
works. It is how fbdev was designed to work. As for 3D support, making
3D work on a per user basis is not very different from the way direct
rendering works today.

Supporting multiple users, one on each CRTC, has long been a feature
request from people building low end educational systems, kiosks,
Internet cafes, etc. If the entire graphics subsystem is going to get
rewritten this feature should be added.

After designing this I think you will find that the extra code that
needs to go into the kernel is minimal. You have to split the video
memory into multiple pools and keep people from accessing queues that
they don't own. Code like this is supposed to be in the kernel.

Having a multi-megabyte root priv graphics process always running is a
scary security exposure. This privileged process is not necessary and
through proper design it can be eliminated. After designing this I
think you'll find that less than 1%  of the code ends up in the driver
and the rest can run unprivileged in user space. Put the root priv
code into the device driver where it will get the scrutiny it needs.

>
>         Jeff
>
>
>

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