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
| ||
|
Date: Mon, 21 May 2007 18:14:23 +0100 From: "Dave Airlie" <airlied@...il.com> To: "Jon Smirl" <jonsmirl@...il.com> 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 > > 1) Be upwards compatible with the existing fbdev drivers. This lets us > avoid rewriting the 90 existing drivers. New drivers shouldn't break > any old apps. > done. > 2) Address the long outstanding issue of multi-seat at the console > level. My solution to this is the one device per CRTC model. done. > > 3) Eliminate the need for a root priv controlling process. Get rid of > the potential for a security hole. Stupid idea, we need something to control policy, this isn't going in the kernel, it can be a lot smaller than X and auditable.. sticking the DRI protocol in the kernel is just pointless.. > 4) OOPS should always display even if in a graphics mode possible to do. > > 5) Support Secure Attention Key (SAK). possible to do. > 6) Eliminate the existing VT swap driver free for all. I would compile > out the VT layer and replace it with a compatible API that enforces > some sanity. I'm hoping to look into this but it is a parallel problem to what this code does, the VT switch API sucks rocks, so providing something compatible is going to suck rocks.. > 7) Support Unicode on the console This just needs a userspace console again a parallel problem that really isn't much to do with the problem set this work is trying to solve... it should enable it... > > 8) Allow multiple user space graphics systems to run. These user space > systems should not touch the hardware, instead they ask the kernel > driver to manipulate the hardware on their behalf. Of course the > kernel driver is only the minimum code needed to arbitrate control of > the resources - it doesn't do things like implement drawing > algorithms. No problems. > > 9) Booting on non-VGA hardware still needs to work. > > 10) Support things like cloning and output device selection. > No problems. Dave. - 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/
Powered by blists - more mailing lists